Rust lacunae

Rust lacunae

In at least one large engineering organisation I'm aware of, Rust is displacing C++ in internal tooling, and there are people looking at using it in customer-facing code because the internal tooling that's written in Rust has the performance characteristics of tooling written in C++, but with many fewer bugs, and all of those bugs being either non-security or in the FFI layer to existing C++ libraries that are being reused.

I would not bet on Rust displacing C++ in the next 5 years; I also wouldn't bet on C++ retaining dominance in the next 20, because the Rust ownership and borrowing model is the killer feature over C++17 (the current internal standard for C++ in that organisation). And the problem with the ownership model is that it needs full ecosystem buy-in to be useful - everything has to respect it in order for it to give benefits - which means that a C++23 with a Rust ownership model will take decades to upgrade existing C++ code to the point where it's useful.

With Rust, because there's a clear FFI boundary (e.g. using the CXX crate), you get tooling assistance in enforcing the model at that boundary, and with experience, it becomes clear when a bug is in the FFI layer or C++ code, and when it's in Rust.