Rewriting the world in Rust — Bitfield Consulting
Blog RSS
Jun 23
Jun 23 Rewriting the world in Rust
John Arundel
“Perhaps we should not replace the payroll system, the avionics stack, and the office kettle firmware all before lunch.”
Image by Cady Galleta
If you have a very large (millions of lines of code) codebase,<br>written in a memory-unsafe programming language (such as C or C++), you<br>can expect at least 65% of your security vulnerabilities to be caused by<br>memory unsafety.
—Alex Gaynor, What<br>science can tell us about C and C++’s security
In recent years, governments have called for universal adoption of<br>memory-safe languages—and especially Rust—to improve software security.<br>Microsoft has also argued for Rust as its default language for new<br>projects.
—The Register, Microsoft<br>wants to replace all its C and C++ code by 2030
More and more critical software is being written in Rust, which is<br>great, but what about the software that’s already been written?
The modern world runs on hundreds of millions of lines of<br>memory-unsafe code: Linux, Windows, databases, cloud infrastructure,<br>mobile operating systems, banking systems, embedded devices, medical<br>equipment, IoT. In other words: basically everything.
Should we rewrite all of it in Rust? Could we?
And where would we even start?
Some things that won’t work
The current proposals seem to boil down to two main approaches:<br>“rewrite everything from scratch”, or “auto-translate it all to bad<br>Rust”. Both of these are horrible, horrible ideas.<br>Let’s not do them.
We’ll touch on a few slightly more practical strategies and tools for<br>migrating large and complex codebases to Rust. But first, let’s explode<br>a couple of myths.
Myth 1: the stop-the-world<br>rewrite
“Good news, everyone: we’re stopping all feature work for the next<br>two years while we rebuild the product from scratch in Rust.”
No maintenance. No bug fixes. No customer-visible improvements. Just<br>an expensive parallel rewrite that probably won’t work properly for<br>quite a while.
No sane business is volunteering for this. Not gonna happen.
There’s a reason you haven’t heard about anyone doing this<br>“stop-the-world” Rust rewrite successfully: it’s a fundamentally bad<br>idea.
“Ah, but wait,” say the AI evangelists. “You haven’t heard my AI<br>pitch yet.”
Myth 2: AI will fix<br>everything
You might have read the post by a slightly over-enthusiastic<br>Microsoft researcher about using AI tools to automatically<br>translate the 50 million lines of C++ code in Windows to Rust by<br>2030. It got a lot of press, and that’s no surprise: if this kind of<br>thing were really possible, it would be amazing.
Microsoft later walked this back a little, emphasising that it’s a<br>long-term research project aimed at building AI-powered tools to help<br>with code migration. In other words, this isn’t possible yet,<br>and probably never will be, in the sense of “AI just does all the hard<br>work for us”.
Unfortunately, while AI tools are effective at small-scale tasks,<br>their performance gets worse and worse as you ask them to do bigger<br>jobs:
For tasks that would take a human under four minutes—small bug<br>fixes, boilerplate, simple implementations—AI can now do these with<br>near-100% success. For tasks that would take a human around one hour, AI<br>has a roughly 50% success rate. For tasks over four hours, it comes in<br>below a 10% success rate.
—Alasdair Allan, The<br>ladder is missing rungs
So, as a rough guide, if it would take you more than four hours to<br>migrate your project to Rust (and it would), then AI won’t<br>magically solve the problem . Even if you could afford the token<br>costs, you’d probably spend more time reviewing, correcting, and<br>integrating the generated code than you would have spent implementing<br>large parts of it yourself.
AI can be useful as a supervised accelerator, but it’s not an<br>autonomous migration engine. The Ladybird browser project recently<br>migrated a subcomponent to Rust with AI assistance,<br>but this wasn’t a “fire and forget” deal: they used hundreds of small<br>prompts, steering the AI agents carefully at each stage and pausing<br>frequently to clean up the inevitable issues.
Lost in translation
Automated translation, whether via AI or tools like c2rust, can produce<br>working Rust programs, but the result often feels less like native Rust<br>and more like C++ wearing a fake moustache. It’s not idiomatic<br>Rust.
The problem is that Rust is a very different<br>language from C++, and many of the differences are precisely<br>the reasons people want to migrate: memory safety, ownership, data race<br>prevention, and so on. These aren’t surface syntax changes: they’re<br>fundamentally different ways of structuring programs.
Much existing C++ code is also deeply object-oriented, with<br>complex inheritance hierarchies and tightly-coupled mutable state. Rust<br>deliberately pushes developers toward different design patterns.
If you just transpile C/C++ to Rust, you will very likely produce<br>rather inefficient code using refcounts all over, or code which...