Why rewriting giant codebases in Rust is a costly fantasy

Roughly 70 percent of the vulnerabilities Microsoft assigns CVEs to each year are memory-safety issues. John Arundel argues giant C and C++ estates do not become safe just because you decide to rewrite them in Rust. The world still runs on memory-unsafe code across Linux, Windows, databases, cloud systems, mobile stacks, banking software, embedded devices, medical gear, and IoT, and that reality does not disappear because a team gets excited about ownership and borrow checking.

The rewrite fantasy falls apart on contact with the schedule

A stop-the-world rewrite sounds clean only until you price it. Freezing feature work, bug fixes, customer work, and platform maintenance for years is not a strategy most organizations can survive, especially when the codebase already carries the business. The moment you ask engineering, product, support, and revenue teams to wait for a full Rust replacement, the plan stops sounding modern and starts sounding like a bet against the company’s own operating model.

Rust is a strong target for memory safety, but the move to Rust has to fit into the constraints of a living system: old APIs, existing build graphs, shipped binaries, and all the boring compatibility glue that keeps customers from noticing your internal language choices.

Memory safety is the real problem, not language fashion

Google has called Rust one of the strongest tools available for addressing memory-safety problems. Memory-safety problems keep showing up in production software, year after year.

Government guidance has now caught up to that reality. CISA and NSA published joint guidance in June 2025 that explicitly pushes organizations toward practical memory-safe roadmaps instead of vague ambition. CISA also published related findings on June 26, 2024, focused on the scale of memory-safety risk in selected critical open source software.

The winning pattern is usually incremental, not theatrical

Rust is already in wide use across Android and other Google products. The Android team has focused on interoperability with C++ as what makes that adoption workable at scale. Microsoft is rewriting SymCrypt, its cryptographic library used in Windows, Azure Linux, Xbox, and other platforms, in Rust, which is exactly the kind of narrow, high-value component where Rust pays off first.

The successful move is usually to isolate one part of the stack, especially something security-critical, and replace it without ripping apart the rest of the system. Interop layers, leaf libraries, parser code, and components with clear boundaries are where Rust adoption gets traction fastest. Rust may not fit every product application, but better interoperability makes adoption possible.

For teams deciding where to start, the decision rule is straightforward:

• Start where memory bugs are most costly and the boundaries are cleanest.
• Favor components that already have a narrow API surface.
• Keep C++ interop working instead of treating it as a temporary embarrassment.
• Measure the cost of replacement against the cost of keeping the existing module alive.

If a component is tightly woven into a dozen subsystems and ships customer-facing behavior every week, it is a bad rewrite candidate. If it is isolated, security-sensitive, and painful to harden in place, it is a much better Rust target.

AI can speed migration work, but it does not erase it

The AI pitch is the second seductive myth, and it deserves the same level of skepticism. Translation tools can move code quickly, but speed is not safety. A Bun rewrite from Zig to Rust showed the trap clearly: the generated code preserved many unsafe patterns and still needed a very large amount of human review. That is exactly what experienced engineers should expect. AI can produce a Rust-shaped artifact; it cannot automatically produce trustworthy Rust.

They imagine a large codebase can be fed to a model and re-emerge as idiomatic, memory-safe Rust, then discover that the output still needs deep review, boundary cleanup, and architecture work. If the source system was unsafe, the translation often carries the same habits forward in a new syntax.

So treat AI as a drafting tool, not a migration oracle. It can help with mechanical translation, boilerplate, and first passes on isolated modules. It is not a substitute for designing ownership, tightening interfaces, proving invariants, and deciding which pieces should not be touched at all.

How to evaluate Rust without turning it into a salvation narrative

The right question is which parts of that codebase can be made safer, cheaper to maintain, or easier to reason about with Rust without stalling the business. Microsoft, Google, and the broader ecosystem have approached it that way. The Rust Foundation has support from Microsoft, Amazon AWS, and Google.

Microsoft made its 2019 case for a safer systems programming language, Google published its 2021 Android Rust work, 2024 brought guidance on interoperability, and 2025 brought the memory-safe roadmap push.