RIIR in 2026: Rewriting in Rust Is Real, But Not a Silver Bullet
A reality check on the 'Rewrite It In Rust' movement, based on a Rustikon 2026 talk. The authors examine real-world rewrites, showing that Rust can deliver performance and safety gains, but not automatically. They highlight the risks—new bugs, failed projects like Prisma and the curl/hyper integration—and the practical challenges of binary size and licensing. The verdict: incremental adoption beats full rewrites, and Rust's success in the Linux and Windows kernels is its biggest validation.
The last 5% of a rewrite is almost always harder than you expect.
- collinfunk
Note, I am a co-maintainer of GNU coreutils. Whether that makes my opinion relevant, biased, or both, you can decide. :)
I really wished the documented their benchmarking methodology here, or at least cautioned the reader not to jump to conclusions based on the benchmarks shown.
GNU 'sort' performance can drastically be altered by the locale in use, the input, and the arguments given to the --buffer-size and --parallel options. GNU 'sort' is fairly conservative in how many threads it will use by default, and in my experience, much more so than uutils. This is because throwing more threads at 'sort' may make it faster (or may not), but also risks running out of memory. This is an issue with uutils, which is poor at deciding when to use external sorting:
$ export LC_ALL=C
$ for i in {a..z}; do yes $i | head -n $(numfmt --from=iec 512M) | tr -d '\n' >> input; done
$ time sort input > /dev/null
real 0m24.245s
user 0m0.896s
sys 0m19.161s
Here is the same command using the latest uutils commit compiled with 'make PROFILE=release':
$ time uu-sort input > /dev/null
Killed uu-sort input > /dev/null
real 2m53.560s
user 1m40.634s
sys 0m59.847s
The process gets killed by the OOM killer. This is likely because uutils 'sort' decides to use 18 threads, instead of the 1 used by GNU 'sort'. I find it a bit frustrating that benchmarks are thrown out without any methodology or citations, because they are often trusted without question. These could b […]
- kmaitreys
This topic has somewhat recently acquired a connotation where it yields a polarized response. People seem "tired" of the language and the episodes like Bun rewrite don't help, especially in current LLM-obsessed era.
Amidst this, just let me try to give my own experience with language while working in a field where it doesn't have much traction (scientific/numerical programming). A couple of years ago, after being tired trying to make Python faster, I was looking for a language to write simulation code in. Fortran (and C/C++) has been the go-to choice in my field for decades but I wanted to try a modern language. I tried Julia but the workflow didn't come naturally to me. Also by default, it also wasn't ahead-of-time compilable. Rust was my second choice but it's type system/design, expressiveness and tooling (rust-analyzer) won me over. I have written so much of it and I really enjoy writing it. Borrow checker isn't really an issue 99% of time when writing scientific code. And when it is (self-referential data structures), you can just use an arena (or something equivalent). The C/Fortran inter-op is great so it's still so easy for me to build my own abstractions on top for the more general stuff like solving ODEs and sparse matrices.
And of course, there is speed, memory safety and ability to parallelize things so effortlessly (rayon is magical), but I feel those were never the things that actually won me over. The language was just a joy to write.
- ameliaquining
This post advocates rewriting incrementally instead of all at once. Just like Joel said back in 2000, and like everyone continues to always say to this day. Yet in practice, people don't actually do this; complete rewrites in Rust remain far more common than incremental ones, particularly when rewriting from a language other than C. The high-profile exceptions, like Linux, Windows, and Firefox, are codebases so huge and ancient that they obviously cannot be rewritten from scratch. When rewriting from scratch is an option, it tends to be taken.
The reason for this is pretty straightforward: Incrementally porting a codebase from another language to Rust (especially if it's not C) is a deeply unpleasant experience, because the interop tooling isn't good enough and you spend most of your time fighting it. Consider the case of rewriting from C++; in the simplest case, you use bindgen and cbindgen, which only work with extern "C" functions in both languages. So you effectively have to rewrite each API first from idiomatic C++ to C-in-C++, then translate to C-in-Rust, then rewrite again in idiomatic Rust. And then repeat for the next API. And so on. It's not going to take long for most programmers to go "screw it, I don't care what Joel said, at least when I rewrite all my work I'll be doing it in one language where anything can call anything else". cxx and autocxx modestly improve things, but still leave you with an impoverished API vocabulary and similar problems, and you still ha […]
- bragh
That comparison figure of LaTeX vs Typst is ridiculous, choosing math-dense example for LaTeX vs classical markdown text for Typst. Yes, Typst syntax is much simpler https://typst.app/docs/reference/math/ but one doesn't need to make unfair comparisons to make Rust look better, Rust has a lot of good things going for it anyway, for example cargo.
- tonyedgecombe
For a brief second I thought JetBrains were rewriting their tools in Rust and we were going to get some performance improvements.