The post on Ziggit landed with the kind of quiet defiance that tends to precede internet arguments. "This is my WIP fork of Bun," wrote GitHub user jazzzooo on July 24, 2026, "based on the last commit before their Rust rewrite."
The project is called Buz—a name that sounds like either a bee or a buzzer, depending on your mood—and it represents what some see as more than just another open-source fork. It's a stake in the ground for developers who believe Bun's original Zig foundation was abandoned too soon, a technical referendum delivered in code rather than Medium posts.
Buz claims sub-second incremental builds, an all-Zig codebase, and a continuation of the path Bun itself has been systematically dismantling. Whether that makes it a lifeline or a dead end remains very much an open question.
The Rust Question No One Asked For
Timing, in software as in comedy, is everything. Bun's pivot to Rust—publicly documented through spring and summer coverage, including reporting by The Register—came with the full weight of modern tech orthodoxy behind it. Memory safety. Ecosystem maturity. The kind of tooling support that makes institutional adoption easier. And, perhaps more controversially, the assistance of Anthropic's AI agents, which reportedly helped with the porting work according to The Register.
For most developers, that's a sensible evolution. For a vocal minority, it felt premature.
Buz doesn't argue the point explicitly. It simply offers an alternative: the last known good Zig commit, cleaned up, refactored, and pointed toward a future where Zig—not Rust—powers a Bun-like runtime. Jazzzooo makes no explicit claims about superiority in the README. The project README opens with warnings, not promises. But the statement is implicit in every line of refactored build configuration.
Speed as a Feature, Chaos as a Caveat
The headline attraction is compilation speed, and here Buz leans into Zig's strengths with single-minded focus. By consolidating Bun's sprawling build process into a unified build.zig file and building vendored dependencies like WebKit's JavaScriptCore from source, the project enables incremental compilation across the entire stack. The result, according to jazzzooo's early reports: sub-second rebuilds during active development.
Currently, that's achieved using the mold linker. Once Zig's native linker gains a few missing capabilities—an "if" that carries its own set of assumptions—jazzzooo expects build times could drop below 300 milliseconds. It's the kind of optimization target that makes sense if you're a developer who reflexively reaches for the rebuild command dozens of times an hour. For everyone else, it's a solution in search of a workflow.
The refactoring effort also excised over 11,000 lines of what the project labels "dead code" from Bun's original codebase, considered technical debt reduction aligned with improvements in Zig 0.16's incremental compilation primitives. Fair enough—though it's worth noting that "dead code" in one developer's eyes can be "edge case handling" in another's.
What It Can't Do (Which Is Most Things)
For all the speed talk, Buz is emphatically not ready for anything approaching real use. The documentation is admirably blunt about this: only x86_64 Linux GNU builds are in scope. The upstream Bun test suite doesn't pass yet. The vendored JavaScriptCore is outdated, with known, unpatched vulnerabilities sitting in the dependency tree like small ticking clocks.
"Do not use in production," the README states, and that's not hedging—it's gospel.
There's also no affiliation with Oven, Bun's parent company, or with Anthropic. Buz contributions fall under the Unlicense, a choice that maximizes freedom and minimizes organizational overhead, though it also signals this is fundamentally a solo effort at the moment. Third-party dependencies retain their original licenses, because copyright law still exists even when you're forking aggressively.
The LLM Governance Experiment
Here's where things get strange, or at least unconventional. Jazzzooo has stated that human-coded contributions will not be accepted until the codebase reaches what's described as a "sane enough shape." Instead, the project is leaning heavily on large language models for cleanup and rewrite work, with automated reviewers—whimsically named Sol Max or Fable Max—serving as gatekeepers for pull request quality.
It's a governance model that raises eyebrows, perhaps more than it should in 2024. The irony isn't lost on anyone: Bun itself is using AI assistance to port to Rust, while Buz is using AI assistance to stay in Zig. The tooling has become sufficiently agnostic that it can argue both sides of the language wars.
Reactions in the Ziggit thread were predictably mixed. Some developers questioned long-term maintainability under such constraints; others saw it as a pragmatic bootstrap strategy for a single maintainer drowning in technical debt. The policy is explicitly temporary—once test parity improves, human contributions are expected to be welcomed—but it underscores just how experimental this entire endeavor remains.
Ecosystem Context: Two Projects, One Fork Point
Buz isn't working in isolation, though it may be working alone. A parallel effort called Cruller emerged around the same time, also continuing Bun's Zig lineage on version 0.16, though with different architectural priorities and a separate community thread. Whether these projects will converge, compete, or simply coexist as variations on a theme is unclear. Open source has room for redundancy, sometimes more than it has room for coordination.
The broader backdrop here is a familiar one: the Zig-Rust divide, which is less about technical merit and more about philosophy, ecosystem momentum, and the kind of trade-offs different communities are willing to make. Zig maintainers publicly criticized aspects of Bun's original Zig implementation and raised questions about the viability of large-scale AI-driven rewrites—criticisms that Bun's move to Rust seemed designed, at least in part, to sidestep.
Buz doesn't engage those critiques directly. It simply keeps building in Zig, as if the conversation never happened.
Early Signals, Uncertain Trajectory
Within 48 hours of the announcement, Buz circulated through the usual channels: Ziggit, Reddit's r/Zig, the aggregators that treat Hacker News like a wire service. The project repository shows signs of early activity—build instructions, dependency lists, test invocation commands—but no independent benchmarks have surfaced yet. The sub-second build claims remain developer-reported, backed by Zig's documented compiler capabilities but not third-party validation.
Community feedback ranged from encouragement to document the build speeds with video evidence, to skepticism about whether a codebase of Bun's complexity can realistically be maintained in Zig without significant institutional backing. Those are questions that won't resolve quickly, and probably not cleanly.
What Happens Next (Probably)
Jazzzooo's stated goal is to reach parity with Rust Bun 1.4.0 "in a few weeks or months," a timeline that depends on fixing tests, re-enabling sanitizers, and closing the gap on security patches. Platform support beyond x86_64 Linux isn't on the roadmap, which narrows the audience but also keeps the scope manageable—perhaps the only way a solo-maintained fork survives past the honeymoon phase.
Whether Buz becomes a meaningful alternative or a footnote in the runtime wars hinges on variables the project can't control. Zig's linker needs to mature on schedule. Contributors need to tolerate working under LLM-first constraints during the bootstrap period, which is a harder sell than it sounds. And a community needs to coalesce around the idea of maintaining a Zig-native Bun descendant at all—not just cloning the repo, but actually caring enough to sustain it.
For now, Buz is an experiment with fast builds and honest warnings. Developers interested in Zig-based runtime evolution have something concrete to point to, even if pointing is about all most of them should be doing with it. Installing it on anything that matters would be, to put it mildly, premature.
But in the messy, contentious world of language ecosystems and runtime development, sometimes a premature fork is exactly what's needed. Not because it will succeed, but because it proves someone thought it was worth trying.
