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 […]
- BluSyn
Small related anecdote:
Was just testing latest gen LLM capabilities, and decided to give it goal of rewriting a small opensource project in Rust. (Should be noted: was not some tiny library, but an actually useful network service).
It completed the entire rewrite from typescript to rust in about 2 hours, ~600k tokens used. Worked perfectly on first try with no follow up changes required. Memory and CPU usage now a tiny fraction of TS version (obviously). Rust code was simple, easy to read, accurate test suite, etc.
I was pleasantly surprised.
Obviously bigger code bases with more complex business logic will likely struggle here, but there are some advantages to "RIIR" when performance matters, even security benefits aside. Rust can help squeeze more juice out of old hardware; reduced memory footprint especially helpful with current RAM prices.
For small services where operational cost matters, having LLMs "rewrite it in rust" might be worth the spend.
- tonyedgecombe
For a brief second I thought JetBrains were rewriting their tools in Rust and we were going to get some performance improvements.