Zig's creator on Bun going Rust: 'not a language problem'

4 min read 1 source multiple_viewpoints
├── "Bun's switch to Rust is rational but driven by ecosystem gravity, not language superiority"
│  └── Andrew Kelley (andrewkelley.me) → read

Kelley concedes Bun's stated reasons — Rayon/Tokio parallelism, crates.io depth for things like SIMD JSON, and a larger Rust-fluent hiring pool — are legitimate, but frames them as bets on ecosystem maturity rather than a verdict on Zig-the-language. He pointedly notes Zig could have gotten there eventually, and that the multi-engineer-year rewrite window will produce zero new features for Bun users.

├── "The migration is about concurrency ergonomics and hiring, not performance"
│  └── top10.dev editorial (top10.dev) → read below

Argues that Bun's Zig implementation already sits within 5% of the theoretical performance ceiling, so any Rust throughput gains will be lost in the noise. The real prize is Rust's Send/Sync traits and borrow checker, which let teams ship multithreaded code without the manual audit burden Zig's approach demands — plus a much larger hiring pool.

└── "Losing Bun as a flagship reference is a real blow to Zig's production credibility"
  └── @kristoff_it (Hacker News, 305 pts) → view

The HN submission framing highlights that Bun was one of Zig's marquee production users and that Kelley himself acknowledges the stakes. The 305-point, 216-comment reception underscores that the community reads this as a materially significant defection from Zig's most visible reference customer.

What happened

Andrew Kelley, the creator and BDFL of the Zig programming language, published a measured 2,000-word response to Bun's announcement that it is progressively rewriting parts of its JavaScript runtime from Zig into Rust. Bun — the runtime that ranked among the fastest-growing developer tools of 2024–2025 — was one of Zig's marquee production users. Losing it as a flagship reference matters, and Kelley knows it.

Kelley's core argument: Bun's decision was rational, but it's a bet on ecosystem gravity, not a verdict on Zig-the-language. He walks through Bun's stated reasons one by one — better parallelism story via Rayon and Tokio, a deeper crates.io ecosystem for things like SIMD-accelerated JSON parsing, and a larger hiring pool of engineers who already know Rust — and largely agrees with the framing while pushing back on the implication that Zig couldn't have gotten there eventually.

The post is notable for what it doesn't do. Kelley doesn't relitigate the Rust-vs-Zig safety debate, doesn't cite benchmarks where Zig wins, and doesn't accuse Jarred Sumner of premature migration. He does note, dryly, that the rewrite is projected to take "multiple engineer-years" and that Bun's users won't see a single new feature during that window.

Why it matters

The interesting signal here isn't that Bun is switching languages — it's *why* they're switching, and the reasons have almost nothing to do with performance. Bun's original Zig implementation is fast. Benchmarks published as recently as spring 2026 show it holding within 5% of the theoretical ceiling on most HTTP and I/O workloads. If Rust wins the rewrite race on throughput, it will be by single-digit percentages — well inside the noise floor of anyone's real workload.

What Rust actually gives Bun is different. First, concurrency ergonomics. Rust's `Send`/`Sync` traits, backed by the borrow checker, let a team ship multithreaded code without the audit burden Zig's manual approach demands. For a runtime that increasingly wants to lean into worker threads and parallel bundling, that's real leverage. Second, crates.io. When Bun needs a well-tested WebSocket implementation, a QUIC stack, or an ICU wrapper, Rust hands them one. Zig, at version 0.14 and still pre-1.0, does not. Third, hiring. The Rust engineer pool is roughly 20x the Zig pool by any reasonable estimate — Stack Overflow's 2025 survey put Rust at 13.5% of professional developers using it, Zig at under 1%.

Community reaction on Hacker News (305 points, top of the front page) split along predictable lines. Zig partisans argue Bun is trading one debt for another — Rust compile times, they note, will make Bun's own iteration cycle slower, possibly by 3-4x. Rust proponents point to Servo, Deno's runtime layer, and the wider async ecosystem as evidence that this is where the industry is converging. The most interesting take in the comment thread came from a former Bun contributor: "Zig is a great language to write. It's a hard language to *maintain a team on.*" That distinction — writing vs. maintaining — is the whole ballgame.

Kelley's response implicitly concedes the maintenance point. He argues Zig's answer is a 1.0 release and a more aggressive push on the package manager (which shipped in 0.11 and is still finding its footing). Whether that lands in time to matter for the next Bun-sized project is the open question.

What this means for your stack

If you're picking a systems language in 2026 for a greenfield project, the honest tradeoff isn't "memory-safe vs. fast" — it's "mature ecosystem with slow builds vs. lean ecosystem with fast builds and more footguns." Rust wins on libraries, tooling, hiring, and formal safety guarantees. Zig wins on compile speed (often 5-10x faster on a clean build), C interop (drop-in, no bindgen dance), and cognitive load (the language spec fits in your head; Rust's does not).

For most teams shipping a product, Rust is now the safer bet — not because of the borrow checker, but because you can hire for it and find a crate for anything. The exception is if you're doing heavy C interop (game engines, embedded, kernel work), where Zig's `@cImport` and cross-compilation story remain best-in-class. TigerBeetle, Ghostty, and River are quietly proving Zig can support serious production systems — just not necessarily ones that need to move as fast as Bun did.

The practical read for JavaScript-runtime users is boring: nothing changes for you soon. Bun's rewrite is incremental — modules are being ported one at a time behind stable APIs. You will not need to change your `bun install` or `bun run` invocations. If anything, you should expect a stagnation period where new features slow down while the team pays down the migration cost. Plan accordingly if Bun is on your critical path.

Looking ahead

The larger story here is that language choice at the systems level is increasingly a bet on ecosystem inertia, not on syntax or semantics. Rust has won that bet for the current cycle — the same way Go won it a decade ago for network services and Java won it two decades ago for enterprise. Zig's window to challenge that isn't closed, but it narrows every time a Bun-sized project makes the same calculation. Kelley's post reads less like a defense and more like a founder taking a public loss with grace while quietly reorganizing the roadmap. Watch what Zig ships in the 1.0 window — that's where the real answer lives.

Hacker News 556 pts 485 comments

My Thoughts on the Bun Rust Rewrite

→ read on Hacker News

// share this

// get daily digest

Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.