Zig Creator Slams Bun's Rust Rewrite, Says 'We've Been Waiting to See This'

Background of the Zig–Bun relationship

When Jarred Sumner first joined the Zig community, his rapid experimentation was described as “novice vigor” – fast learning but not polished engineering. Bun attracted attention as a high‑performance JavaScript toolchain. Although Bun could have survived on community donations, it took venture funding and publicly thanked Zig for performance contributions, donating $60,000 per year to the Zig Software Foundation.

Shift after venture funding

According to the post, once Bun became VC‑backed, Jarred’s role changed from an open‑source collaborator to a deadline‑driven manager. Interviews with former Oven (Bun’s company) employees reported consistent problems: poor communication, unrealistic expectations, and lack of empathy.

Code‑quality concerns

The Zig team regularly reviews important user projects to monitor language‑design impact, breaking‑change risk, and performance regressions. Their review of Bun’s code found extensive hacks, heavy use of assert, and a pattern of adding features without allocating time for bug fixing or technical‑debt reduction. The author states the code was “sloppy” before any large‑language‑model involvement.

Five technical challenges to the Bun rewrite blog

Challenge 1 – Style guide vs. language features is a false dichotomy

The Bun blog argues that choosing Rust over C++ is a trade‑off between “style‑guide policing” and “language‑level safety”. The counter‑argument cites the TigerBeetle project (a high‑reliability database written in Zig) as evidence that quality comes from substantial engineering effort to find and fix bugs, not merely from language features.

Challenge 2 – Inconsistent claims about the test suite

The Bun blog claims that massive testing combined with machine translation is sufficient to catch all bugs. The critique asks why Zig’s existing test suite still leaves many bugs, yet a completely new million‑line codebase would suddenly be fully covered.

Challenge 3 – Performance gains attributed to LTO, while Zig already supports LTO

The Bun blog credits cross‑language LTO (link‑time optimization) for performance improvements. Zig has supported LTO since Bun’s inception and even enabled it by default for a period. Later it was disabled due to numerous LLVM bugs that also affect Rust.

Challenge 4 – Fuzzing allegations

The Bun blog mentions prior fuzzing of its Zig code. Direct communication with the Bun team indicated that no fuzzing was performed, leading the author to label the claim as fabricated.

Challenge 5 – Binary‑size optimizations unrelated to the rewrite and missing compile‑speed data

The blog discusses binary‑size reductions achieved through engineering tricks, but those optimizations are unrelated to the Rust rewrite and should have been applied while the codebase was still in Zig. The critique also points out misuse of Zig’s comptime feature, which can slow compilation. No compile‑time comparison is provided; for reference, the Zig compiler (≈600 kLOC) compiles cold in ~16 seconds and incrementally in ~90 ms.

Key technical observations

Early collaboration involved performance contributions from Zig to Bun.

Post‑VC shift introduced management pressures that, according to interviews, degraded engineering practices.

Code review revealed systematic hacks and overreliance on assertions, indicating insufficient technical debt management.

LTO support existed in Zig from the start; LLVM bugs affecting LTO were known to both Zig and Rust.

Claims of extensive fuzzing were contradicted by the Bun team.

Binary‑size reductions were performed after the rewrite, not as part of it, and compile‑time impact was not disclosed.

Zig’s own compile‑time metrics (cold 16 s, incremental 90 ms) provide a baseline for any future comparison.

Reference: My Thoughts on the Bun Rust Rewrite – https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html