The replacement myth
You open a repository for a popular game engine or a financial trading platform. The codebase runs three million lines of C++. You read a blog post claiming Rust will eat C++ for breakfast. You feel a pang of panic. Should you rewrite it? The short answer is no. The longer answer involves understanding how software ecosystems actually evolve. Languages rarely replace each other overnight. They carve out new territory while the old guard adapts.
How language adoption actually works
Think of programming languages like construction materials. Reinforced concrete did not replace steel. It changed how we build skyscrapers. Steel handles tension. Concrete handles compression. You use both in the same building. C++ is the steel. It has been around since the 1980s. It has decades of optimized libraries, mature toolchains, and engineers who know exactly where the cracks form. Rust is the high-strength composite. It offers better safety guarantees out of the box and a more predictable build process. It does not erase the value of the older material. It just makes certain types of construction safer and less prone to catastrophic failure.
The industry does not wipe hard drives to switch languages. It adds new tools to the belt. When a team needs a new service, they pick the language that minimizes risk and maximizes velocity. When they need to maintain a legacy system, they keep using the language that already works. This is why you see Rust in new operating system components, web assembly runtimes, and CLI tools. You still see C++ in game engines, high-frequency trading platforms, and embedded firmware. Both are moving forward. C++20 and C++23 brought modules, concepts, and coroutines. Rust stabilized async/await and improved its macro system. The gap narrows in some areas and widens in others.
Stop looking for a winner. Look for the right tool for the specific job.
The friction of rewriting
Rewriting a large system is a famous trap. The second system effect guarantees you will underestimate the complexity of the original code. You will miss edge cases that took years to discover. You will spend months rebuilding what should have been a week of work. The compiler will catch your memory errors, but it will not catch your architectural blind spots.
Consider a simple data structure. In C++, you might write a custom allocator to avoid heap fragmentation. In Rust, you reach for Box or Vec. The Rust version is safer and faster to write. But if that allocator was tuned for a specific hardware cache line, the Rust version might actually perform worse until you profile and optimize it. Safety does not equal performance. It just removes an entire class of bugs so you can focus on the ones that remain.
/// A cache entry that tracks expiration without manual memory management.
struct CacheEntry {
data: Vec<u8>,
expires_at: std::time::Instant,
}
fn main() {
// Rust forces you to think about ownership upfront.
// You cannot accidentally return a dangling pointer here.
let entry = CacheEntry {
data: vec![1, 2, 3],
expires_at: std::time::Instant::now(),
};
// The compiler tracks when `entry` goes out of scope.
// No manual destructor calls. No double frees.
println!("Cache size: {}", entry.data.len());
}
The code above compiles and runs without a single memory leak. That is the baseline in Rust. In C++, you get the same result only if you follow RAII strictly, use smart pointers everywhere, and audit every constructor. The cognitive load is different. Rust shifts the work from runtime debugging to compile-time reasoning. C++ shifts the work to runtime discipline and static analysis tools. Both approaches produce working software. They just demand different habits.
A quick convention note: the Rust community standardizes on cargo for builds. You do not write Makefile rules or configure CMake for simple projects. cargo handles compilation, testing, and dependency resolution in one command. It formats code identically across teams. You save hours of tooling friction and spend that time writing logic instead.
Trust the build system. Let it handle the plumbing while you focus on the architecture.
Where Rust actually wins
Teams adopt Rust when the cost of a memory safety bug outweighs the cost of learning a new language. A network daemon handling untrusted input is a prime candidate. A buffer overflow in C++ can become a remote code execution vulnerability. The same bug in Rust panics safely or returns an error. The system stays up. The attacker gets nothing.
Look at the Linux kernel. The maintainers did not rewrite the kernel in Rust. They added Rust support for new drivers and subsystems. Existing C code stays in place. New code that benefits from zero-cost abstractions and borrow checking gets written in Rust. The build system handles both. The FFI layer translates between them. This is the realistic pattern. You do not replace. You integrate.
Web assembly follows the same path. C++ compiles to WASM and runs in browsers. Rust compiles to WASM and runs in browsers. The difference is tooling. wasm-pack and cargo provide a smoother path from source to deployment. C++ requires manual linker flags, export maps, and careful ABI management. Rust handles the heavy lifting. That convenience drives adoption in frontend tooling and server-side runtimes.
When you cross the FFI boundary, the compiler will reject mismatched types with E0308. That error saves you from silent memory corruption at runtime. You fix the type signature before the code ever ships.
Write the new safety-critical paths in Rust. Keep the legacy C++ where it belongs. Connect them cleanly.
The traps to avoid
Assuming Rust is automatically faster is the first trap. The borrow checker prevents data races, but it does not optimize your algorithms. An O(nĀ²) loop in Rust is still slower than an O(n log n) loop in C++. You still need to profile. You still need to understand cache locality. You still need to avoid unnecessary allocations.
Ignoring modern C++ is the second trap. C++20 introduced std::span, std::format, and concepts. C++23 added std::expected and improved coroutine support. Many of the pain points that drove developers to Rust have been addressed in the standard library. You do not need to leave C++ just to get better error handling or range-based views. You just need to update your compiler and your habits.
Underestimating the ecosystem is the third trap. C++ has decades of battle-tested libraries for graphics, physics, and numerical computing. Rust's ecosystem is growing rapidly, but it is not yet a drop-in replacement for every domain. You will spend time writing glue code. You will encounter crates that are still finding their API. You will read documentation that assumes familiarity with ownership semantics. That friction is real. It is not a flaw. It is the cost of a younger ecosystem.
Another convention worth knowing: the community treats unsafe blocks like loaded weapons. You keep them as small as possible. You wrap them in a safe API. You document the invariants in a // SAFETY: comment. You never scatter unsafe across a codebase. You isolate it, test it, and move on.
Measure before you migrate. Profile before you optimize. Rewrite only when the math actually works.
Choosing the right tool
Use C++ when you are maintaining a legacy codebase that already works. Use C++ when you need access to mature, highly optimized libraries for graphics, physics, or scientific computing. Use C++ when your team has deep expertise in manual memory management and ABI stability is a hard requirement. Use C++ when the project timeline does not allow for a new language learning curve.
Use Rust when you are starting a greenfield project that handles untrusted input or network traffic. Use Rust when memory safety is a strict requirement for compliance or security audits. Use Rust when you want a predictable build process with zero-cost abstractions and no hidden dependencies. Use Rust when your team values compile-time guarantees over runtime flexibility.
Use a mixed approach when you need to incrementally modernize a large system. Write the new safety-critical components in Rust. Keep the performance-tuned legacy modules in C++. Connect them with a clean FFI boundary. Isolate the unsafe code. Document the invariants. Let each language do what it does best.
Pick the language that matches your risk tolerance. Ship software that stays secure.