> Issues with C++ safety aren't just a matter of a dangling pointer that should've been a unique_ptr or shared_ptr. It's massively naive to think that this would in any way be comparable to Rust.

While I agree, I would point out that in the same way that "safe" Rust is a usable (if difficult to get used to) subset of "unsafe" Rust, there also exist usable safe subsets of C++ [1]. Tooling to enforce that Rust code strictly conform to the safe subset, of course, already exists (and is built into the compiler). Such enforcement tools do not yet exist for C++ code, but I think they're coming. And I think they'll probably support safe subsets that are more convenient/intuitive/easier-to-use than (the current version of) safe Rust.

I wonder if adopting Rust to avoid the pervasive unsafe code in C++ isn't a little bit akin to adopting Esperanto to avoid the pervasive cursing in English. I mean, there does exist a non-vulgar subset of the English language, even if it's difficult to persuade people to stick to it :) But then, if all the cool kids are talking Esperanto...

> (If it did, I presume Mozilla would've rewritten Firefox in C++11/14/17 instead of Rust. Oh wait, they already use C++11...)

I think this may be a missed opportunity by the Firefox developers. If you look at the code, they're still using new/delete and raw pointers targeting dynamic objects. I presume that a lot the code has survived from the pre-C++11 era. I think converting their code to a safe subset of C++ (like SaferCPlusPlus) would be quicker and require less effort than a rewrite in Rust.

[1] for example (shameless plug): https://github.com/duneroadrunner/SaferCPlusPlus