Bun Is Rewriting Itself in Rust — and It Already Passes 99.8% of Tests

What happened

Jarred Sumner announced that Bun's experimental Rust rewrite has reached 99.8% test compatibility on Linux x64 glibc. For a runtime that ships a bundler, transpiler, package manager, test runner, and Node.js-compatible API surface in a single binary, that number is staggering. Passing 99.8% of an existing test suite during a full language rewrite means the new implementation isn't a prototype — it's a near-drop-in replacement.

Bun was originally written in Zig, with performance-critical sections using C++ interop (notably JavaScriptCore bindings). Zig was chosen early on for its promise of C-level performance with better ergonomics and comptime metaprogramming. The decision to rewrite in Rust represents one of the most significant language migrations in the JavaScript tooling ecosystem.

The announcement, which surfaced on Hacker News with a score north of 500, immediately reignited the perennial Zig-vs-Rust debate — but the real story here isn't about language wars. It's about what happens when a fast-moving infrastructure project outgrows the ecosystem of its implementation language.

Why it matters

### The Zig bet didn't fail — Bun outgrew it

Zig is a genuinely compelling language. Its comptime system, lack of hidden control flow, and zero-overhead interop with C make it a strong choice for systems programming. But Zig is still pre-1.0. The compiler has breaking changes between versions. The package ecosystem is small. Hiring developers who know Zig is hard. For a hobby project or a focused library, these are acceptable tradeoffs. For a runtime that hundreds of thousands of developers depend on, they become existential risks.

Bun's Rust migration isn't a verdict on Zig's technical merits — it's a verdict on ecosystem maturity as a production dependency. Rust offers a stable compiler with a predictable release train, `cargo` as a battle-tested package manager, and a hiring pool that's grown dramatically since 2020. The `crates.io` ecosystem means Bun's team doesn't have to hand-roll every data structure and protocol implementation.

### What 99.8% compatibility actually means

Let's talk about that number. A full rewrite hitting 99.8% test pass rate on the first target platform means the Bun team likely took an incremental, module-by-module approach rather than a big-bang rewrite. The remaining 0.2% almost certainly represents edge cases in platform-specific behavior, timing-sensitive tests, or intentional behavioral changes.

The specification of "Linux x64 glibc" is telling. This is Bun's highest-volume platform — the one that matters most for CI pipelines, Docker containers, and production servers. By targeting Linux x64 glibc first, the team is optimizing for the platform where correctness matters most and where regression risk is highest. macOS, Windows, and musl-based Linux (Alpine) will follow, but getting the primary platform right is the correct sequencing.

For context, consider what Bun's test suite covers: HTTP server behavior, file system operations, `node:` module compatibility, bundler output, JSX/TSX transpilation, package resolution, and the FFI layer. Each of these touches different system APIs and has different performance characteristics. A 99.8% pass rate across all of these subsystems suggests the Rust rewrite preserves not just correctness but behavioral compatibility at a granular level.

### The performance question

Bun's original value proposition was speed — faster installs, faster starts, faster everything. The natural question is whether a Rust rewrite maintains, improves, or regresses on performance. While specific benchmarks haven't been published for the Rust branch yet, there are reasons to be cautiously optimistic.

Rust and Zig are both zero-cost abstraction languages that compile to native code via LLVM. In micro-benchmarks, they typically perform within a few percent of each other. The performance differences between Rust and Zig Bun will likely come down to algorithmic choices made during the rewrite rather than language-level overhead. A rewrite is an opportunity to fix hot paths that were identified after the original implementation shipped — and the Bun team has years of profiling data to guide those decisions.

The more interesting performance angle is compilation speed and binary size. Rust's compile times are notoriously longer than Zig's, which could slow down Bun's development iteration cycle. On the other hand, Rust's mature LTO (link-time optimization) and codegen options give fine-grained control over the final binary.

### Community reaction and the language-war trap

The Hacker News discussion predictably split into camps: Rust advocates celebrating validation, Zig advocates mourning a high-profile defection, and pragmatists pointing out that the language choice matters far less than the engineering team's ability to ship. All three perspectives have merit, but the pragmatists are closest to right.

The real signal here is that the JavaScript tooling ecosystem is converging on Rust. SWC (used by Next.js and Parcel), Turbopack, Rolldown (Vite's upcoming Rust bundler), Oxc (linter and parser), Biome, and now Bun — the list of Rust-based JS tools grows every quarter. This creates a flywheel: more Rust JS tooling means more shared infrastructure (AST formats, sourcemap libraries, resolver implementations), which makes building the next Rust JS tool easier.

What this means for your stack

If you're running Bun in production today, the short answer is: nothing changes yet. The Rust rewrite is experimental and the existing Zig-based Bun continues to receive updates. When the Rust version ships, the API surface will be identical — that's what 99.8% test compatibility means.

If you're evaluating Bun for a new project, this is actually a positive signal. A team willing to undertake a full rewrite to improve long-term maintainability is a team thinking about the next five years, not the next release cycle. The Rust rewrite suggests Bun is transitioning from a scrappy challenger runtime into infrastructure that's being engineered for institutional longevity.

For teams contributing to Bun or building plugins and extensions, the shift to Rust lowers the barrier to contribution. The Rust ecosystem has better IDE support (rust-analyzer), better documentation tooling (docs.rs conventions), and a larger pool of developers who can read and review code. Zig's smaller community meant that Bun's contributor funnel was inherently constrained.

If you're a Zig enthusiast, this is a moment for honest reflection rather than defensiveness. Zig's strengths — comptime, explicit allocators, C interop — are real. But a language's ecosystem maturity matters as much as its technical design, especially for projects that need to scale their contributor base and dependency graph.

Looking ahead

The 99.8% number on a single platform is a milestone, not a finish line. The Bun team still needs to bring macOS, Windows, and musl Linux to parity, resolve the remaining 0.2% of failing tests, and run extensive real-world compatibility testing against the npm ecosystem. The transition period — where both Zig and Rust codebases coexist — will be the most demanding phase for the team. But if the Rust rewrite ships with equivalent or better performance and full compatibility, it will be the most significant runtime rewrite since io.js merged back into Node. The JavaScript runtime wars just got a Rust-flavored plot twist.