On Rust Rewrites
Someone looks at a mature codebase written in C, C++, or even Go, feels the weight of its accumulated sharp edges, and reaches for Rust as the clean slate.
I have felt that pull myself more times than I care to admit. The promise is intoxicating: memory safety without a garbage collector, fearless concurrency, and a compiler that refuses to let certain classes of disaster leave the machine.
If you have spent nights chasing use-after-frees or data races, the idea of starting over in a language that simply will not allow those failures feels like relief.
Yet the decision is rarely as clean as the language’s type system.
A rewrite is not a free upgrade. It is a multi-year commitment disguised as a technical choice.
Feature parity is harder than it looks. Edge cases that the original system handled through years of battle-tested hacks do not magically reappear.
Performance wins that look dramatic in microbenchmarks often shrink once the full workload, the allocation patterns, and the integration surface are taken into account.
Teams discover that the hardest part was never the language but the domain knowledge encoded in the old code, the operational muscle memory, and the quiet assumptions that never made it into documentation.
I have watched rewrites that succeeded because the original system had become an active liability.
I have also watched rewrites that stalled halfway, leaving two incomplete systems and a team that lost momentum.
Get John Philip’s stories in your inbox
Join Medium for free to get updates from this writer.
The difference usually had little to do with Rust itself.
It had everything to do with whether the rewrite was solving a real, measured pain or satisfying an aesthetic preference for modernity.
Rust is excellent at preventing entire categories of bugs.
It is not a substitute for product discipline, careful scoping, or the humility to keep the old system running until the new one is genuinely better.
What keeps me returning to the idea, even after seeing the failures, is the long-term calculus.
Once a system is written in Rust and the team has internalized the ownership model, the cost of future change drops.
Concurrent features become safer to add and refactors stop feeling like Russian roulette.
The language’s constraints start to feel less like friction and more like a form of permanent code review that never sleeps.
That compounding effect simply arrives later than the initial excitement suggests.
So I no longer treat rewrite it in Rust as a slogan.
I treat it as a high-stakes engineering bet that must clear a higher bar than enthusiasm.
The language delivers what it promises.
The question is whether the project, the team, and the timeline can absorb the full cost of making that promise true.
