Ah, the "bad code" fallacy. If we hadn't had enough experiences already, the article we are disucssing here clearly shows, how difficult it is, to get C/C++ code reasonably error free. Yes, there exist a free applications, which are pretty good in that respect, but if your goal is to be error-free, the development time balloons. And you are often limited to very simple memory allocation schemas. If you think that "smart pointers" should be used, why not just use a memory-safe language?

Well, smart pointers will still result in a more predictable program. Modern GCs are amazing. But it's hard to be super predictable with them.

I would argue that most of the memory errors actually pertain to C programs, not C++ ones (providing they use proper encapsulation and libraries such as STL).

C is syntactically C++ being a subset of C++ and I've seen many programs which claim to be C++ but are actually programmed using C methodologies.

Chrome is a heavy user of such tools and has many talented engineers working on it.

Citation needed. I never see the same level of dedication in big Google or Facebook projects as in well run smaller projects like SQLite.

You are directly rewarded for "new" features (i.e. plagiarizing or rewriting old ones and selling them as new).

So I don't think the engineers are particularly talented, and the incentives are not the same as for SQLite.

If using Rust results in fewer bugs for less money, shouldn't we still do it?

The reason SQLite can test so thoroughly is that their requirements never change. I have tried to browse the web with SQLite but so far no luck.

Actually, sqlite has its share of memory safety issues. https://bugs.chromium.org/p/chromium/issues/list?q=Type%3DBu... (and to be clear, this is just a coarse search, and the bugs there aren't necessarily all bugs in sqlite, but there are definitely some)

Do you think issue at google is not knowing about/not using the proper tools?

No, the issue is that the incentives are wrong (features, features, features for promotion) and indeed the engineers (on average) are not that talented.

Features (user tracking and fancy options) over stability.

Why do we see the version of Chrome reaching 100 at a sustained pace, instead of seeing something like Chrome 8.X or 9.Y?

The pressure is all about introducing new features (and thus, more bugs!) while fixing the existing bugs slowly.

And we should stop thinking that all the brilliant minds are working at FAANG, because it isn't true.