What's Going On With Bun's Rust Rewrite?
A bombshell dropped in developer circles this week when a leaked look at Bun's unreleased Rust port revealed something that made systems programmers do a double-take: 13,365 unsafe blocks scattered throughout the codebase. For context, Rust's entire value proposition rests on memory safety — and the unsafe keyword is essentially an escape hatch that bypasses those guarantees. Having thousands of them in a single project is, to put it diplomatically, a conversation starter.
Bun, the JavaScript runtime built by Jarred Sumner and his team at Oven, has been making waves since its debut by promising blazing-fast performance largely through its tight integration with Zig and WebKit's JavaScriptCore engine. The revelation that the team has been quietly working on a Rust port — and that the port contains an extraordinary number of unsafe blocks — has ignited a fierce debate about what "rewriting it in Rust" actually means in practice.
Why This Is Trending Right Now
The story blew up on Hacker News and across developer Twitter/X almost simultaneously. It touches several raw nerves in the programming community at once: the ongoing "Rewrite It In Rust" (RIIR) culture wars, the real-world complexity of migrating performance-critical code, and the question of whether Rust's safety guarantees are meaningful when a project leans this heavily on unsafe code.
For many developers, Rust is nearly a religious commitment. Its promises around memory safety have been used to justify enormous migration efforts at companies like Microsoft, Google, and even within the Linux kernel. Seeing a high-profile project appear to use unsafe at industrial scale feels, to critics, like wearing a seatbelt only around your neck.
What "Unsafe" Actually Means in Rust
The Technical Reality
To be fair to the Bun team, unsafe in Rust isn't necessarily a red flag on its own — it's a necessary tool when interfacing with C libraries, performing low-level memory operations, or squeezing out maximum performance. Virtually every serious Rust project has some unsafe code. The Rust standard library itself uses it extensively.
The issue isn't the presence of unsafe blocks. It's the density. Thirteen thousand-plus unsafe blocks in an unreleased port suggests either that this is a relatively mechanical translation from an existing non-Rust codebase (possibly from the existing Zig/C++ code), that the port prioritizes performance parity over safety abstractions, or that the codebase is still in an early state where safe abstractions haven't been layered over raw operations yet.
What the Critics Are Saying
Prominent voices in the Rust community have pointed out that if the safety guarantees aren't being honored, you're essentially writing C with a different syntax. Others are more measured, noting that this could represent a work-in-progress and that safe wrappers might be added before any public release. The honest answer is that without seeing the code directly, it's impossible to judge how well-encapsulated those unsafe blocks actually are.
Impact on Bun's Reputation and the Broader Ecosystem
Bun has cultivated a reputation as a performance-obsessed, pragmatic runtime that doesn't shy away from unconventional choices — like building on Zig when everyone else was reaching for Rust or C++. The team's willingness to explore a Rust port signals maturity and a genuine interest in long-term maintainability. But the unsafe block count has given ammunition to skeptics who've questioned whether Bun's engineering decisions prioritize benchmarks over correctness.
For Node.js and Deno users watching from the sidelines, this saga reinforces that runtime development is extraordinarily hard, and that no team — however talented — gets a free lunch on performance and safety simultaneously.
What to Expect Next
The Bun team hasn't officially commented in depth on the specifics of the Rust port, and since it remains unreleased, the codebase is presumably still evolving rapidly. What's likely is that Oven will eventually address these concerns directly, either by reducing the unsafe count through better abstractions or by providing technical justification for why the current architecture makes sense. The developer community will be watching closely. If anything, this moment could push the team toward greater transparency about their engineering tradeoffs — which would ultimately benefit everyone building on top of Bun. The runtime wars are far from over, and how Bun navigates this credibility challenge will say a lot about whether it can graduate from a brilliant experiment to a truly production-grade platform.