I agree that safety aspect in C++ has improved in its modern versions. But, these modern features are best practices as documented in C++ core guidelines. The issue with best practices is that it cannot be enforced. That is, lets say everybody on my team follows the latest guidelines. We even have latest static analysis tools. However, the same cannot be said about the 3rd party libraries that we will use. In this regard, Rust is much better since the every line of code is subjected to the same strict rules.

Offcourse, one can argue that the 3rd party Rust libraries can use a lot of "unsafe" code which we as consumer may not know about. But the situation is still better than C++.

Until people routinely use a RefCell equivalent in C++, abandon APIs like string_view, stop mutating directly through shared references, and stop using multiple threads (or C++ somehow finds a way to encode thread safety into its type system), most C++ programs that are memory safe are only so by coincidence. The whole point of Rust is to make memory safety a locally provable property, and even modern C++ has far too many idioms that abandon that local provability to make global memory safety feasible in large programs.

> it's not too hard to be "memory safe" in modern c++.

I'm not entirely convinced that is the case, but surely you will agree that it's much easier to audit Rust for memory-safety than C++.

...by avoiding the parts that are the legacy of C.