Blazingly Fast or Blazingly Hyped? A Reality Check on Rewriting in Rust

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 Fish shell all belong here. These are not small bets. Some of the most widely deployed software in the world now contains Rust, and it got there through this category.

Rust rewrite performance: Does it actually deliver?

Sometimes, yes. Sometimes for the wrong reasons. Looking at uutils, sort runs almost four times faster than GNU sort. The reason is parallel merge sort, which Rust’s concurrency model makes considerably easier to implement correctly. But some other utilities are faster simply because they’re a fresh rewrite with 30 years of hindsight. The original project couldn’t experiment as freely because production users depended on it.

The PNG crate is a better example of Rust-specific gains. The Rust implementation is nearly twice as fast as libpng. Part of this comes from auto-vectorization: the Rust compiler generates SIMD instructions automatically from a regular for loop, while most C implementations require hand-written SIMD. The other part comes from streaming DEFLATE decompression, which fits more data into the CPU cache at once. Both are genuine Rust advantages.

Rust binary size: The problem and how projects solve it

Rust binaries are famously large, and the reasons are real: panic handling code, Debug trait implementations, the standard library compiled into each binary, monomorphization from generics, and static linking of all dependencies.

uutils dealt with this through a multicall binary format, the same approach used by BusyBox. All utilities are compiled into one binary and invoked through symlinks. The result: 73 MB of individual binaries becomes 13.8 MB as a multicall binary, which actually beats the 18.4 MB of the GNU coreutils standard install. Compressed with UPX, it gets down to 5 MB.

The problem is solvable, but it requires serious effort.

Rewriting in Rust: What can go wrong and why?

This part doesn’t get talked about enough. Every rewrite introduces new bugs. You’re writing code from scratch, which means you’ll inevitably introduce new bugs or regressions not found in the original project. This isn’t a Rust problem specifically; it’s a software rewrite problem. But it’s worth being clear-eyed about.

Cloudflare introduced an unwrap in a request-scoring component. uutils formatted dates slightly incorrectly, breaking unattended upgrades. sudo-rs echoed a partially typed password back to the terminal after a timeout. The first CVE in Rust code in the Linux kernel came from a race condition in an unsafe block in the Android binder driver. TARmageddon was an RCE vulnerability in async-tar caused by incorrect parsing of the .tar format.

If projects backed by significant funding and experienced teams still make these mistakes, we will too. That’s not a reason not to rewrite, but it is a reason to take testing seriously.

Sometimes, Rust isn’t even the right choice at all. Microsoft chose Go for the TypeScript compiler rewrite largely because Go is much closer to TypeScript in its programming model, which mattered while the codebase would contain both languages for quite some time. The NTPsec project chose Go because, at the time, Go had better network primitives and a less fragmented ecosystem. These were reasonable decisions, not failures of imagination.

And some rewrites that chose Rust still didn’t succeed. Prisma migrated away from their Rust query engine back to TypeScript due to skill-set gaps, deployment complexity, and runtime issues. Loglog Games abandoned Rust after three years of game development. They found it excellent for refactoring but poor for iteration speed, and noted that the Rust game development community focuses more on engine technicalities than on shipping finished games. The curl/hyper integration got to 95% completion and was then abandoned due to the difficulty of the last 5% and the lack of community momentum. Interestingly, the collaboration still benefited both projects: the process of trying to integrate them led to forced cleanups in both codebases.

Licensing is a real decision

One thing that doesn’t get discussed enough in RIIR conversations is that if you’re creating a new project that reimplements an existing one, your license choice has consequences.

A more restrictive license, like GPL, may exclude users who can’t introduce copyleft dependencies into proprietary projects. A more permissive license may draw criticism from the open source community, as some fear companies will use the code without contributing back. There’s no universally correct answer. It depends entirely on your project’s goals and community. But it’s a decision worth making consciously rather than by default.

Is the RIIR movement still happening in 2026?

The RIIR meme has faded somewhat. But the actual movement hasn’t. Rust in the Linux kernel is no longer experimental, and the maintainers declared the experiment a success at the 2025 Maintainers Summit. Rust is running in the Windows kernel. Cloudflare, Firefox, and countless infrastructure projects have committed significant Rust code to production.

The scale is real. Between Linux and Windows alone, Rust is running on billions of devices. That’s arguably the biggest validation the “rewrite it in Rust” idea has ever received.

How to actually do it well

If you’re considering a rewrite, a few things we’d recommend thinking through first. Make sure it actually makes sense for your use case. Ask whether your codebase is in a memory-unsafe language, whether it’s critical software, whether you have real performance and reliability requirements, and whether you have significant parallel or concurrent code that’s hard to reason about. The more of those boxes you check, the stronger the case.

Make sure your team is ready. Either they already know Rust, or they’re genuinely willing to learn and contribute to it. Google’s data suggests that around two-thirds of developers feel confident contributing to a Rust codebase within two months. But that’s not a guarantee, and the last 5% of a rewrite is almost always harder than you expect. Small rewrites take months. Medium ones take one to two years, and large rewrites take two to five. It almost always takes longer than you estimated.

Prefer expanding incrementally over rewriting completely. Adding new components in Rust while keeping the old codebase running is almost always less risky than a full replacement. You get the benefits without betting the whole project on it.

When you do rewrite, build a serious test suite. The best example of this in practice is uutils, which runs against the official GNU coreutils test suite to track parity. As of early 2026, they’re at 92.2% pass rate and climbing.

So is it worth it?

If your project is written in a memory-unsafe language, handles critical functionality, has real performance requirements, and involves substantial concurrent code, yes. A rewrite is strongly justified, and the evidence supports it.

Outside of those conditions, it’s still potentially worth it, but the analysis needs to be more careful. The enthusiasm is understandable as Rust is genuinely good. But it was designed as a systems programming language, and that’s where it does its best work. Treating RIIR as a default answer to every performance or safety concern is how you end up with a two-year rewrite project that ships six months late and introduces bugs you already fixed.

Frequently Asked Questions

What does RIIR mean?

RIIR stands for Rewrite It In Rust. It started as a suggestion in open-source issue trackers to migrate C and C++ projects to Rust for memory safety and performance, and became a broader cultural meme in the Rust community.

Is rewriting software in Rust worth it?

It depends on your situation. If your codebase is in a memory-unsafe language, handles critical functionality, and has real performance or concurrency requirements, the case for a Rust rewrite is strong. In other situations, the benefits are less clear, and the costs, but the learning curve, rewrite time, and new bugs deserve serious consideration.

What are the risks of rewriting in Rust?

Every rewrite introduces new bugs, including bugs the original project already fixed. Rust rewrites also require developers to learn the language, can take significantly longer than estimated, and may face challenges with platform support, binary size, and interoperability with other languages.

What is the best approach to migrating to Rust?

Incremental expansion rather than full rewrite. Add new components in Rust while keeping existing code running. When you do rewrite, invest in a thorough test suite that validates the new implementation behaves identically to the original.

Did Rust succeed in the Linux kernel?

Yes. At the 2025 Linux Kernel Maintainers Summit, the consensus was that the Rust experiment was a success. Rust is now a core part of the kernel and is no longer considered experimental.