Rewriting in Rust: Performance, Failures, 2026 Reality Check
RustRover
Focus on what matters
Follow
Follow:
X X
Download
RustRover<br>Blazingly Fast or Blazingly Hyped? A Reality Check on Rewriting in Rust
Irina Mihajlovic
This is a guest post by Mateusz Maćkowski and Marek Grzelak, co-maintainers of cot.rs and speakers at Rustikon 2026. You can watch the full talk here.
RIIR. If you’ve spent any time in open source communities, you’ve seen it. Someone opens an issue on a C or C++ project and suggests rewriting in Rust for memory safety and performance. Sometimes it’s a serious proposal. Sometimes it’s a meme. In 2026, it’s honestly a bit of both.
We wanted to find out which one it really is. Not in theory, but by looking at what actually happened when people did it. The wins, the performance numbers, the projects that were abandoned three years in, and the CVEs that showed up in freshly written Rust code. We’ve been in this ecosystem long enough to have seen all of it, and this blog post, based on our talk on Rustikon 2026, was our attempt to give it an honest look.
TL;DR
RIIR can deliver real performance and safety gains, but not automatically. Some projects are faster because of Rust, some just because they were rewritten from scratch.
Rewrites introduce new bugs. Even well-funded teams with experienced engineers make mistakes.
Not every rewrite succeeds. Prisma, Loglog Games, and the curl/hyper integration all hit walls for different reasons.
Binary size, platform support, and interoperability with other languages are real practical challenges.
The best approach is almost always to expand incrementally rather than rewrite everything at once.
Rust in the Linux kernel and Windows is arguably the biggest validation the RIIR movement has ever had.
What is RIIR? Why did it take off?
RIIR stands for Rewrite It In Rust. The phrase started appearing in issue trackers on C and C++ projects as a way to suggest migration to a memory-safe, performant alternative. According to Google Trends, the "rewrite rust" term started climbing significantly around 2022, which we think aligns roughly with the Rust 2021 edition release, though a lot happened around that time, and we wouldn’t claim to know for certain.
The reasons people reach for Rust when considering a rewrite come down to three things:
Memory safety
Performance
Fearless concurrency
On memory safety, the Android team’s data is hard to argue with. After Android began transitioning new development to memory-safe languages, the velocity of Rust code in the codebase steadily increased. The data shows a clear linear correlation: as the velocity of memory-unsafe code decreases, so does the number of memory safety vulnerabilities.
In terms of performance, a 2017 paper comparing energy efficiency, execution time, and memory usage across programming languages ranked Rust near the top for both energy efficiency and execution speed. The methodology is not perfect, and direct comparisons between languages are difficult, but the results still point to a broader trend: Rust performs competitively on both speed and efficiency. Memory usage was higher than the absolute best performers, but still within the upper half of the comparison.
And then there’s the Stack Overflow Developer Survey. Rust has been the most admired language for years running. A lot of RIIR projects probably exist simply because developers want to write Rust. That’s worth being honest about.
Three types of rewrites
Not all rewrites are the same, and it helps to be specific about what category you’re talking about. Here we have three categories.
Drop-in replacements aim to be functionally identical to the original. You replace the binary and nothing else changes. Projects like uutils coreutils, sudo-rs, youki as a container runtime replacement, and Arti as a Tor reimplementation all fall under this. There are thousands of these across the ecosystem, ranging from small file format libraries like the PNG crate replacing libpng, to larger infrastructure projects with serious corporate and community funding behind them.
Alternatives solve the same problem but make different choices. ripgrep instead of grep, delta instead of diff, bat instead of cat, Typst instead of LaTeX, Polars instead of pandas. These aren’t trying to be identical replacements. They’re often faster, more ergonomic, or designed with a different philosophy. Typst is a good example of the readability argument:
LaTeX and Typst can produce the same output, but the source code tells a very different story. And on raw performance, Marek ran both ripgrep and grep against a 37 GB cargo target directory searching for the word "cot". grep finished in 52 seconds. ripgrep finished in six. That’s not a marginal difference.
Self-rewrites are when an existing project decides to rewrite part or all of itself in Rust, without replacing an external binary. Firefox, the Linux kernel, Windows, Cloudflare’s infrastructure, and the...