Is the Rust Rewrite Movement Truly Blazingly Fast or Just Blazingly Hyped?

At Rustikon 2026, two RTB House engineers presented data‑driven findings on the ongoing “Rewrite It In Rust” (RIIR) trend, questioning whether the hype matches reality.

Why developers consider Rust rewrites

Memory safety : Google’s Android policy discourages unsafe code, and a clear linear correlation between unsafe‑code lines and memory‑safety bugs is shown.

Performance : A 2017 study comparing languages found Rust near‑top in energy efficiency and speed, though actual gains vary per project.

Fearless concurrency : Ownership, borrow checking, and the Send/Sync traits make concurrent code easier to write correctly.

Stack Overflow surveys also rank Rust as the most loved language for several years, fueling the “why not?” mindset.

Three categories of rewrites

Drop‑in replacement : Direct binary compatibility (e.g., uutils coreutils, sudo‑rs, tty‑rs, PNG/tar libraries, Youki container runtime).

Parallel alternatives : Same problem, different approach (e.g., ripgrep, bat, jj, just, Typst, Polars, Bun rewrite).

Self‑rewrite : Projects internally replace parts with Rust (e.g., Codex CLI, Fish shell, Cloudflare infrastructure).

Performance case studies

uutils sort runs almost four times faster than GNU coreutils, mainly due to easier, safer parallelism in Rust. The speedup also benefits from starting a fresh codebase without legacy baggage.

PNG decoder is roughly twice as fast as its C counterpart, thanks to compiler‑generated SIMD vectorization and a streaming decompression design that keeps data in CPU caches.

Conversely, bat in non‑interactive mode is 60× slower than cat, and lsd suffers from many extra system calls, showing that rewrites are not automatically faster.

Binary‑size “gotcha” and mitigation

Rust binaries tend to be large because of panic location info, default Debug implementations, static linking, and monomorphisation. The uutils project applied a multi‑call binary technique (similar to BusyBox) to shrink from 73 MB to 14 MB.

Hidden costs of rewrites

New bugs are inevitable: examples include an unwrap‑induced issue at Cloudflare, date‑format drift in uutils, password‑echo bug in sudo‑rs, a CVE in the Linux Android binder driver, and an async‑tar remote‑code‑execution flaw.

The learning curve is steep; Google’s survey shows about two‑thirds of developers feel confident after two months, but many need longer.

Time estimates reveal small rewrites take months, medium projects 1–2 years, large ones 2–5 years, often overrunning by 2–3×, with the final 5‑10 % being the hardest to complete.

Projects that abandoned Rust

Microsoft TypeScript compiler chose Go over Rust because safety and performance were not critical.

Prisma ORM reverted to TypeScript due to skill‑stack mismatch, deployment concerns, and larger binaries.

LogLog game studio dropped Rust after three years, citing borrow‑checker difficulties and long compile times.

Hyper integration into libcurl stalled at the last 5 % due to limited community interest, though both projects improved code quality.

Licensing considerations

Rewrites often trigger license reevaluation; switching to a more restrictive license (e.g., GPL) may deter commercial users, while a permissive license could invite “free‑riding” criticism.

Final guidance

Rewrite if the existing codebase is unsafe, performance‑critical, and heavily parallel, and if the team can commit to Rust learning, compiler support, and binary‑size constraints. Otherwise, weigh alternatives.

Validate the business case and team readiness.

Prefer extending the system with Rust rather than a full rewrite.

Build a comprehensive test suite; uutils reused GNU coreutils tests to achieve near‑100 % compatibility.

The Rust rewrite movement is neither wholly a miracle nor a myth; it offers genuine performance and safety benefits but also brings substantial engineering overhead.