The rewrite
Bun, the JavaScript runtime, bundler and package manager, has shipped version 1.4, and the headline change has nothing to do with a new feature. Its entire core has been rewritten from Zig to Rust. The last Zig-based release, 1.3.14, was tagged in May 2026; 1.4.0 is the first stable release built on the new foundation.
The reason for switching languages was a recurring category of bug. Bun's Zig codebase mixed garbage-collected JavaScript values with manually managed memory, and that combination kept producing use-after-free crashes, double-frees, and leaks. Zig requires discipline with its explicit defer keyword to clean things up correctly at every call site; Rust's Drop trait and borrow checker turn the same class of mistake into a compile error instead of a runtime crash.
How it was actually done
What makes this rewrite unusual is the process. Bun's creator, Jarred Sumner, ran the port over 11 days in May 2026 using roughly 64 instances of Anthropic's Claude Code coding agent working in parallel across four separate git worktrees. The scale: 1,448 Zig files ported to Rust equivalents, about 16,000 resulting compiler errors divided up and fixed across the agent fleet, and 6,502 commits generated along the way, adding roughly one million lines of code net. Sumner has put the API (application programming interface) cost of the exercise at around $165,000.
The team built two supporting documents first: a PORTING.md file mapping common Zig patterns to their Rust equivalents, and a LIFETIMES.tsv spreadsheet recording the correct lifetime annotations for struct fields, since Rust's memory model requires the compiler to know how long each reference is valid. Before scaling up, they trial-ran the process on three files with one agent implementing and two more acting as adversarial reviewers - instances given only the diff, not the original implementation, and explicitly instructed to find bugs rather than approve the work. That adversarial-review step is what they then applied across the full port.
The company reports zero tests were skipped or deleted during the rewrite, and that 1.4.0 fixes 128 bugs relative to 1.3.14. It also documents 19 regressions the process introduced and then caught, mostly from subtle semantic gaps between the two languages - for instance, Rust's debug_assert! macro has no effect in release builds while Zig's equivalent function-based assert does, and Rust enables bounds checking in release builds by default where Zig's ReleaseFast mode does not.
The numbers that changed
- Binary size: down roughly 20% on Linux and Windows
- Memory use in repeated build loops: 6.7 GB fell to 609 MB across 2,000 builds
- HTTP (Hypertext Transfer Protocol) throughput: up 2.8% to 4.8%
- Claude Code startup time specifically: about 10% faster
- Bundler code-splitting on large dependency graphs: up to 14 times faster; one test case, the jszip library, dropped from a 459 KB output to 149 KB
Version 1.4 also bundles 15 capabilities that previously required external npm packages - image processing, headless browser automation, markdown parsing, and scheduled jobs among them - directly into the runtime as APIs like Bun.Image, Bun.WebView, and Bun.markdown, alongside new support for Node.js's worker_threads, node:cluster, node:repl, and node:domain modules.
Why it's controversial
The rewrite has drawn sharp criticism, most notably from Andrew Kelley, the creator of the Zig programming language itself. Reviewing the codebase, Kelley wrote: "We became increasingly horrified at the programming practices we saw in Bun's codebase. Hacks on top of hacks. Abuse of assertions." Critics have also pointed out that the new Rust code leans heavily on unsafe blocks in places, which undercuts some of the memory-safety argument for switching languages in the first place.
Developer Tero Piirainen, who builds the Nue framework on top of Bun, raised a separate concern: that the project missed several self-imposed release dates over the prior three months and accumulated more than 5,000 open pull requests on GitHub, a volume he contrasted with React's 441. Piirainen also noted the lopsided commit history - roughly 15,800 commits from an automated bot account against 790 from Sumner personally - and suggested the rewrite reads as much like a showcase for Anthropic's own AI (artificial intelligence) coding tools as it does a response to a genuine Zig problem.
The context matters here: Anthropic acquired Bun outright in December 2025, months after adopting it as the runtime for Claude Code, and has committed to keeping it open source and MIT-licensed. That makes the AI-agent-driven rewrite, using Anthropic's own coding agent, a test case the company has a direct stake in succeeding publicly, not just an engineering choice made in isolation.
There's also a downstream risk that has nothing to do with code quality: some projects, like the desktop framework Electrobun, have native bindings written in Zig, C++, and Objective-C layered on top of Bun's internal interfaces. Whether those bindings keep working depends on whether Bun's underlying API surface changes as the Rust core stabilizes - a question that has no answer yet, since no breakage has been reported so far, only the possibility of it.
What it means in practice
If you already run Bun in production, the memory and binary-size improvements are worth upgrading for on their own, and the zero-skipped-tests claim is a reasonable baseline check before you do. If you maintain a project with native bindings that reach into Bun's internals rather than its public JavaScript API, hold off and watch how the Rust core evolves before assuming compatibility. And if you're choosing a runtime for a new project, the more interesting data point may not be the benchmark numbers at all, but the fact that a large, production JavaScript runtime just had its core rewritten in under two weeks by AI agents with no reported loss of test coverage - whether or not you find the code quality convincing, that's a new data point for how much of this kind of migration work can plausibly be automated.
Sources
- Bun (official blog)
- AlternativeTo
- Tero Piirainen
