Buz: a modern Zig fork of Bun that rebuilds in under a second

After Claude Code's migration to Bun (with Rust core) last week, a member of the Zig community announces Buz: a fork of Bun rewritten with recent versions of Zig, promising sub-second incremental builds. 224 points on Hacker News.

The concrete case

Bun (the concurrent JavaScript runtime of Node) is mostly written in Zig, a system language that attracts with its promise "do what C does, but better". Except that as Bun grew, it found itself stuck on a relatively old version of Zig, with compilation times exploding when modifying even just one file.

Enter Buz, a fork announced by a community member on ziggit.dev (the official forum of the Zig enthusiasts) on July 24, 2026. The pitch is summed up in one line: "drop-in replacement for Bun using modern Zig, with sub-1s incremental builds". On Hacker News, the announcement quickly reached 224 points and 161 comments - for a nascent project, that's a signal.

This comes at a pivotal moment for the Bun ecosystem: last week, Simon Willison documented that Claude Code now uses Bun (with a Rust heart) - a sign that Bun is settling into the AI tooling. Every friction on the speed of contribution thus becomes a stake beyond the sole project.

What to understand

The name of the project, Buz ("Bun" + "Zig"), is not just a pun. It documents the technical bet:

• Following recent versions of Zig (the language is pre-1.0, breaking changes are frequent but compiler optimizations are advancing quickly).
• Leveraging Zig's self-hosted compiler, which brings incremental builds worthy of the name.
• Remaining API compatible with Bun to avoid fragmenting the ecosystem (as Deno does vs Node).

The crux of the matter is these sub-second incremental builds. When you hack on such a large runtime, every "I change a line → I test" cycle counts. Going from several tens of seconds to less than a second completely changes the contribution ergonomics - it's the kind of detail that decides whether a project attracts external devs or remains stuck with its founding team.

The real debate

The HN comments are divided into two camps:

1. The enthusiasts - a community-led fork can unlock things that Jarred Sumner (founder of Bun) never had time to tackle. Notable precedent: the forks OpenSSL/LibreSSL, or io.js which forced Node.js's hand.
2. The skeptics - the risk of divergence is real. A "drop-in replacement" that misses 5% of the APIs ends up creating more problems than it solves. And maintaining an active fork of a project as large as Bun requires manpower.

Our take

This is probably more interesting as a proof of concept than as a serious competitor to Bun. If Buz demonstrates that sub-second builds can be achieved on a codebase of this size, the Bun team will have every interest in upstreaming the optimizations - which would benefit everyone. The "fork that pushes the original to move" pattern is a constant in open source.

To watch: the frequency of commits in the coming weeks. A fork that dies after 15 days happens all the time; a fork that lasts 3 months starts to count.

To remember Buz is not yet a credible replacement for Bun, but it points to a real problem: the stagnation of the Zig version used by Bun slows down the project's velocity. Whether Buz succeeds or not, the mechanical effect will be to force Bun to migrate faster - which also ties in with Bun's new positioning in AI tooling (Claude Code).