Bun ditched Zig for Rust — and the rewrite took 11 days, not a year

5 min read 1 source clear_take
├── "This is a disciplined, well-executed use of AI — human review and test suites made it work"
│  ├── Jarred Sumner (Bun Blog) → read

Sumner frames the 11-day rewrite as a methodical engineering effort using pre-release Claude Fable 5 with human review at every step, using Bun's extensive test suite as ground truth. He presents the results — memory leaks fixed, 20% smaller binary, ~5% faster — as evidence that careful AI-assisted porting can outperform the original hand-written code.

│  └── @didibus (Hacker News) → view

Reads the post as a model example of disciplined AI use — no vibe-coded merges, human review at every step, test suite as the source of truth. Argues this is what responsible AI-assisted engineering looks like in practice.

├── "The rewrite results are a damning verdict on Zig"
│  └── @Philpax (Hacker News) → view

Delivers the sharpest critique: a naive port away from Zig fixed memory leaks, improved stability, shrunk the binary by 20%, and improved performance by 5%. Argues this can't be good for Zig's reputation, especially since Bun was the flagship production Zig project proving the language could ship serious software.

├── "The Anthropic acquisition makes this a marketing artifact, not a neutral engineering post"
│  └── @top10.dev Editorial (top10.dev) → read below

Notes that the disclosure buried in paragraph one — Bun was acquired by Anthropic in December 2025 — reframes the entire story. The Bun team are now Anthropic employees rewriting their runtime in the language their employer's unreleased model writes best. This isn't a neutral engineering retrospective; it's a demo of Claude's capabilities disguised as a postmortem.

└── "The gains prove the ecosystem debt was in Zig, not in the original code"
  └── @top10.dev Editorial (top10.dev) → read below

Argues that a mechanical port shouldn't produce a smaller, faster, more stable binary — unless the source codebase had accumulated five years of debt in a language whose ecosystem never caught up. The improvements aren't magic from Rust or Claude; they're the natural result of shedding accumulated workarounds for a pre-1.0 language's rough edges.

What happened

On July 8, Jarred Sumner published a post titled *Rewriting Bun in Rust* on the Bun blog. The headline claim: the runtime that started as a line-for-line port of esbuild from Go to Zig — one engineer, one Oakland apartment, one year, pre-LLM — has been ported again, this time from Zig to Rust. The port was done by one engineer using a pre-release Claude Fable 5 and Claude Code. It took 11 days from start to 100% of the test suite passing on every supported platform.

The disclosure buried in paragraph one is the more important number: Bun was acquired by Anthropic in December 2025. Sumner and much of the Bun team are now Anthropic employees. The runtime they ship is being rewritten in the language their employer's model writes best, using an unreleased version of that model. This is not a neutral engineering post.

The naive rewrite produced a smaller, faster, more stable binary: memory leaks fixed, 20% smaller on disk, roughly 5% faster in Sumner's own numbers. That is not the result you expect from a mechanical port. It is the result you get when the source codebase had accumulated five years of debt in a language the ecosystem never quite caught up with.

Why it matters

The community reaction split cleanly. On one side, developers like `didibus` on HN read the post as a careful, disciplined use of AI — human review at every step, test suite as ground truth, no vibe-coded merges. On the other, `Philpax` landed the cleanest one-liner in the thread: *"it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%."* Both readings are correct. Both matter.

The Zig verdict is the part the Zig community will spend the next month arguing about. Bun was the flagship production Zig project — the proof that a small team could ship a Node-competitor in a pre-1.0 language. If the flagship walks, the narrative walks with it. Sumner is careful to say Zig made Bun possible in 2021, and that's almost certainly true. What he doesn't say, but the numbers do: Zig stopped being the right answer somewhere between then and now, and the ecosystem — libraries, tooling, hiring pool, LLM training data — moved to Rust while Zig stayed pre-1.0.

The AI angle is being oversold in one direction and undersold in another. Oversold: the 11-day number will be cited for years as proof that language migrations are now a weekend problem. They aren't. Sumner had full context on the source, wrote the target-language idioms by hand where the model got them wrong, and had a test suite dense enough to catch regressions. Undersold: the actual shift is that language choice is no longer a five-year, one-way door. If you can port a runtime in eleven days, the calculus on "we picked the wrong language three years ago" changes completely. That decision used to end careers. Now it ends sprints.

The commenter `sashank_1509` put the commercial version bluntly: this rewrite would have cost a team of engineers a year. At loaded rates, that's seven figures. One engineer plus an unreleased frontier model did it in eleven days. Whatever you think of the AI-slop discourse, that ratio is the actual disruption — and it lands on staff engineers doing migration work, not on juniors writing CRUD. The people whose jobs were "I know both languages and I can hold the whole system in my head" are now competing with a model that also knows both languages and never gets tired.

There's a fourth thread worth pulling. Commenter `pier25` — who says they've moved back to Node — lists their reasons, and none of them are the rewrite: no LTS on the Zig branch for CVEs, big shipped bugs, an amateurish transition. That's the underrated risk of small-team runtimes: the bus factor is one, and the one has just committed to another year of language-level churn. The Rust rewrite may fix Bun's medium-term velocity. It also means the next 6-12 months of Bun releases carry all the risk of a fresh codebase in production.

What this means for your stack

If you're on Bun in production, nothing changes today. Bun 1.4 will ship on Rust; the API surface Sumner cares about is the JavaScript/TypeScript one, and that's stable. What you should watch is the changelog cadence over the next two quarters. If the release notes start looking like "fixed regression introduced in 1.4.x" three weeks in a row, that's the tell. The 11-day test-suite-passing bar is a lower bound on correctness, not a guarantee.

If you're on Zig anywhere in your stack, this is a signal to price in ecosystem risk. Bun was the reason Zig had a hiring story; without it, the language is back to being a beautiful research project with a very small production footprint. That doesn't make it wrong for your use case. It does mean you should have a written answer to "what happens if we need to hire two more people in 18 months."

If you're on Node or Deno, the honest read is that Bun's velocity just went up, not down. Rust has the library ecosystem, the LLM tooling support, and the hiring pool that Zig never got. A Bun that ships faster is a Bun that catches up to Node's edge cases faster. The Node compatibility gap — the actual reason most teams still haven't switched — closes on a Rust codebase in ways it wasn't going to on Zig.

Looking ahead

The real story here isn't Bun and it isn't Rust. It's that a solo maintainer, with an unreleased model from the company that just acquired him, rewrote a production runtime in less time than most teams take to approve the RFC. Every language migration on every roadmap in the industry just got re-estimated. The ones that were shelved because "it would take a year" are back on the table. The ones that were greenlit because "Rust is the future" now have to justify why they aren't done yet. The awkward part, for everyone downstream of Anthropic: this is what the demo looks like when the model in question isn't out yet.

Hacker News 710 pts 441 comments

Rewriting Bun in Rust

→ read on Hacker News
padjo · Hacker News

It's very odd how quickly people fall back on emotional claims to attack this. Like we're engineers, if you can point at concrete problems with this rewrite I'd love to hear them. Obviously Jared is going to give the positive case, saying that he's doing that doesn't prove t

pier25 · Hacker News

Personally I don't care that they used AI to rewrite Bun to Rust. Even if 1.4 is not good enough it will probably get better over time.What has pushed me back to Node is seeing how amateurish the transition has been handled.- No LTS support for the Zig version regarding CVEs etc.- Huge bugs lik

didibus · Hacker News

Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it.As an aside, I don't know why anyone would not want to use a memory-s

sashank_1509 · Hacker News

I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow.Forgetting

Philpax · Hacker News

Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.

// share this

// get daily digest

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