While it's certainly possible to introduce huge memory safety issues in C++, those usually stem from using C++ as C, i.e. directly allocating and freeing memory, or using plain integers as index variables, or messing with raw pointers etc. C++ contains the tools to minimize (but not entirely eliminate) those potentially difficult to make correct operations. The problem is the defaults are not those safe alternatives, and, especially in large teams, some one some how will use C++ as C eventually.<p>C++ is used in a lot of closed systems (i.e. closed as in 'no chance to communicate with outside code), as in embedded software, weapon systems, etc, so the potential of exploitation of bugs from the outside is very small.<p>Where does this leave Rust? well, if the extra safety is justified by the cost of the change, then Rust is the right choice there. But the cost of change can be really huge, because it's not only the retraining of the developers, but also the tools, the infrastructure, the ecosystem etc. And these can be potentially very expensive to change.<p>Also, C++ is not used alone in systems where increased safety is required. There are lots of tools that can be applied to C++ code to statically discover potential bugs. The combination of idiomatic C++ and of those tools can be cheaper than migrating to Rust and the result could be of the same quality, i.e. bug-free code.<p>In conclusion, using Rust shall be judged, as always, in economic terms: between C++/safety analysis tools and Rust, which one is the cheaper in the short term and long term? that's the question to answer.