There was a paper about rust use in open source projects, looking at vulnerabilities introduced by developers with different contribution histories. They suggest that you need to spend working several years in a C++ codebase to get down to the same defect rate as a new contributor in a rust project.

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fcypherpunks.ca%2F~iang%2Fp...

If that is true, then there is probably little reason to worry.

The interesting thing is more productivity while reducing the number of bugs. Normally reducing bugs requires stricter processes, which typically reduces productivity.

There is increasing pressure on companies to take responsibility for their software products. This includes preasure to move towards memory safe languages. This exercise is about getting C++ of the governments naughty lists, so that people can continue to use C++ without extra regulatory overhead and too much risk to the company.

Rust is just a working example of a language with similar performance to C++, whise approach could be copied. The committee opted to not do that and go for something that does not make the language memory safe at all, but that catches enough bugs to be close enough (they hope).

We'll see whether that is implementable, practical and enough to satisfy regulators.

I have hunted my fair share of core dumps in Qt code. Each one is a memory safety fail... it is, just like the rest of C++ not memory safe.

I find it funny that so many C++ devs seem to think using smart pointers means you are memory safe. It does not, there is so much more needed... check what the "safe C++" proposal set out to change, that's what you need tomdo to make C++ memory safe using the approach rust took. It includes fun stuff like new reference semantics, destructive moves and a new standard library.