Far from it. Until Rust can read C++ code seamlessly, there will be more code written in C++ than Rust for the foreseeable future. HPC, Finance, AI, Games, Databases, Hardware all continue to be written in C++.
I agree momentum for Rust is growing, but disagree that it is obvious the writing is on the wall for C++. Like, Java and C# didn't kill C++, either. In all likelihood, these languages will all coexist for a long, long time.
Java and C# did kill C++. They just did it only in places they were feasible. People forget that before them, it was very common to write application and even serve code in C++. Now Rust is targeting its remaining niche(s).
This is a common misunderstanding. Rust’s type system and borrow checker are not significant reasons for its compile times, and Rust compile times aren’t really worse than equivalent modern C++ code.
But Rust's type system an borrow checker are not something you want to go without in Rust, while in C++ many codebases prevent the use of some features to reduce compile time right?
Modern C++ is characterized by relying on templates for generics and reusability, as well as static dispatch.
“Traditional” C++ looks a lot more like Java, and often like C.
Much of the compile time of both Rust and C++ comes from monomorphization and linking, both of which do a lot of work to support the zero-cost high-level abstractions favored by both languages.
For game development its hard to see how Rust can really replace C++ in practice. It'll take 15 years at minimum to replace the current development ecosystem for building games
Large game engines consist of many medium to large software libraries stitched together. What you're likely to see is that each such library is gradually either rewritten or replaced by Rust code, with an FFI compatibility layer matching the existing ABI where possible.
There's no reason to think that current game engines will have their fundamental APIs around scene management, serialization, entity composition, and so on, ported directly to Rust, because these things are typically designed around available language features. For example, an engine written in C++ might have its own version of `dynamic_cast` and RTTI, and that's going to be an extremely awkward design in any other language.
I think 15 years is too high, but I agree that it will be a while, because a triple-A game engine is a huge investment.
Strange position in 2026. If there is any writing in the wall it is this. Nobody is going to be writing Rust code from scratch given where LLMs are already now, much less in 5 years. A golden rule of software is fresh coding is a small part of the lifecycle most of it is maintenance. You may be able to get people to write Rust code (vibe code it), however a tiny minority of them will want to maintain LLM generated Rust code!! Rust will most likely be an intermediate representation - a security/formality check of sort - before converted into the appropriate heterogenous code across GPU/CPU/TPU/XPUs. Even there some other better representation will supplant it as Rust's ideas will be found too limiting. The idea that you as a programmer will sit and write Rust source code is just going to look very archaic. Thank god for LLMs for saving everyone just in time.
