That's basically how Rust is being treated by those companies. But it's not going to be "drop-in", lots of stuff will have to be refactored to work with Rust's

That's basically how Rust is being treated by those companies. But it's not going to be "drop-in", lots of stuff will have to be refactored to work with Rust's memory model. See, memory management is a hard problem and the complexity involved in solving it has to live somewhere. In C and C++, that complexity lives in the programmer's head. In Java, Python, Go, etc. that complexity lives in the program's runtime in the form of garbage collection. In Rust, that complexity lives in the compiler - with some caveats, Rust code is safe as long as it compiles and passes the borrow checker. However, the ownership-based memory model of Rust is not always trivial to port other code to. Modern, idiomatic C++ written with RAII and smart pointers should be relatively easy to port to Rust, but most of the critical systems code out there is not like that at all. Most of the critical systems code out there is written in C or old-style C++ with C-style strings & arrays and raw pointers to heap memory all over the place. So regardless of what your C/C++ language replacement looks like, it will take some serious effort to replace that kind of code.