Bun Is Leaving Zig for Rust — And It Says More About Open Source Than Languages

The JavaScript runtime wars just took another sharp turn. Bun, the upstart that’s been eating Node.js’s lunch on cold-start times and package installs, is rewriting its core in Rust — abandoning Zig, the language it became famous for choosing. For the Zig community, this isn’t just a defection. It’s the marquee project walking out the door.

A Short, Loud Marriage

When Bun first dropped, the talk on Hacker News wasn’t really about benchmarks. It was about the language. While every other systems-tier project — Deno’s compatibility layer, ruff, uv, Turbopack, Biome — was reaching for Rust, Bun’s founder Jarred Sumner picked Zig. The pitch was simplicity, explicit memory management, and fast compile times. C-like minimalism, without C’s footguns.

And it worked. Bun shipped with 3-4x faster startup than Node.js and a package installer that made npm feel like a fax machine. For Zig, it was the killer marketing line: a real, production-grade product running on a pre-1.0 language.

Why Rust, Why Now

The Bun team’s reasoning lands on three points, and none of them are about raw performance.

First, hiring. Zig still hasn’t shipped 1.0. Hiring an experienced Zig engineer in 2026 is closer to “find someone willing to learn it” than “find someone who already knows it.” Rust, meanwhile, is the lingua franca of a generation of systems programmers — Cloudflare, AWS, Microsoft, and half of GitHub’s trending repos are writing it daily.

Second, the ecosystem. HTTP parsing, TLS, compression, regex engines — Rust has battle-tested crates for all of it. Bun has been hand-rolling or FFI-binding to C libraries to fill those gaps. That’s not engineering leverage; that’s a tax.

Third, stability. Zig’s compiler and build system still break across versions. Every Zig release has cost the Bun team migration work that produced zero user-facing value. For a runtime — where uptime and reliability are the entire promise — that’s an unsustainable drag.

The Zig Community’s Two Reactions

Walk through the Zig forums and Reddit threads and you see the response splitting cleanly in half. One camp shrugs: “this was always coming.” Building a commercial product on a pre-1.0 language was a bet, and the fact that Bun rode it this far is a win, not a loss.

The other camp is genuinely deflated. Zig’s biggest showcase is gone, and the next founder asking “should I build something serious in Zig?” now has a much harder pitch to make. Andrew Kelley, Zig’s creator, kept it brief: people are free to choose their own tools.

The Real Story Is About Open Source

Read this as “Rust beat Zig” and you’ve missed the point. The actual signal is about how mature open-source infrastructure projects pick languages — and how those criteria differ from what a solo developer optimizes for.

Performance-wise, Zig is right there with Rust. But a runtime is a multi-year, multi-decade commitment. Compiler stability, hireable talent, contributor pipeline, and library depth matter more than shaving microseconds. Bun’s team weighed those four and Rust won every category.

There’s also an under-discussed factor: VC money changes the calculus. Bun isn’t a weekend hack anymore — Oven, the company, has raised tens of millions. From an investor’s seat, “codebase written in a language nobody can hire for” is a structural risk. The Rust migration is partly a technical decision and partly de-risking the cap table.

What Founders Should Take From This

When teams evaluate a new language, the conversation usually starts with benchmarks. Bun’s pivot is a reminder that ecosystem beats performance over the long run. For a six-month side project, pick whatever excites you. For infrastructure that needs to live five or ten years, the right question isn’t “what’s fastest in 2026?” — it’s “what will I still be able to hire for in 2031?”

So look at your own core codebase. The language choice you made two years ago — would you make it again today? And more importantly, will the answer still hold in 2031?