I'd say it's actually the other way around. C++ in the abstract is full of half-baked, ill conceived ideas that later had to be deprecated or walked back entirely: std::auto_ptr and memory leaks; std::shared_ptr::unique() not being threadsafe; taking the time to implement bounds checking in std::vector, but the default access operator isn't checked; corner cases with std::initializer_list leading to unexpected behavior.
In practice, most C++ shops seem to limit themselves to a small subdialect of C++ that's reasonably safe. The C++ Core Guidelines are essentially an effort at canonicalizing some of these best practices and building them into the tooling.
I think it's fair to say that Rust or managed code should at least be considered for any greenfield project, maybe even a hard requirement for certain domains like cryptography, networking, financial applications, etc. But I don't believe that every application needs to be security hardened to that level, and the C++ library ecosystem is still much more robust than Rust's is. Crates.io feels like a graveyard of experimental libraries that reached 40% the functionality of their C++ cousins before the commit activity dropped to zero.
In practice, most C++ shops seem to limit themselves to a small subdialect of C++ that's reasonably safe. The C++ Core Guidelines are essentially an effort at canonicalizing some of these best practices and building them into the tooling.
I think it's fair to say that Rust or managed code should at least be considered for any greenfield project, maybe even a hard requirement for certain domains like cryptography, networking, financial applications, etc. But I don't believe that every application needs to be security hardened to that level, and the C++ library ecosystem is still much more robust than Rust's is. Crates.io feels like a graveyard of experimental libraries that reached 40% the functionality of their C++ cousins before the commit activity dropped to zero.