Buz: A Modern Zig Fork of Bun with Sub-Second Incremental Builds
Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
I am developing Buz, a work-in-progress fork of Bun built with modern Zig to replace its Rust-based successor. By porting the entire build graph to build.zig, I have achieved sub-one-second incremental rebuilds, significantly improving the developer loop. My goal is to create a drop-in replacement with a saner codebase by removing over 11,000 lines of dead code and relying more on Zig's standard library. While currently using LLMs to tackle the inherited technical debt, the long-term vision is a maintainable project that rivals the performance of the original.
I can't think of another project whose codebase was so neglected as to reach 11K lines of dead code.
- kristoff_it
To me the most interesting fact about this fork is that it has proven that Bun could have had fast builds all along.
To be fair, there are caveats still in place today: Zig incremental compilation does not yet support aarch64 and only the linux linker supports binary patching, but it's just a matter of time before all major platforms are conquered.
- wsdn
> To this end, LLMs will be used extensively to deslop...
So we're using LLMs to clean up the code that LLMs ruined in the first place? We’ve reached peak tech in 2026.
- robertlagrant
> I’ve cut over 11,000 lines of completely dead code from Bun. I can’t think of another project whose codebase was so neglected as to reach 11K lines of dead code. I’ve also rewritten and modernized parts of the codebase, trying to rely more on Zig’s stdlib. In the process, countless bugs have also been fixed.
This is astonishing. Is anyone else surprised at this dead code figure? Is it a feature of large projects I've just never noticed?
- dmix
> To that end, I’ve cut over 11,000 lines of completely dead code from Bun. I can’t think of another project whose codebase was so neglected as to reach 11K lines of dead code.
How long has this person been programming?
- softwaredoug
This effort makes me think of the tick-tock oscillation between features and code stewardship I’ve experienced on every agent heavy coding project
Tick: go hard after features, build a correct and extremely messy version
Tock: digest what was done, deslopify, improve project aspects that go beyond feature correctness: performance, maintainability, general fragility / sensitivity to change
My experience is spending a day vibe coding a working application. Then a week unslopifying it to make it a viable software project that can sustainably accept more features without the house of cards collapsing.
You sort of did this pre-AI, but then the professional human coder had a stronger mental model of the system, and IMO was going slower that the switch from tick to tock wasn’t as jarring
- evertheylen
Also highly relevant project: Cruller, also uses the pre-register Bun codebase but focuses only on the runtime part for production.
Link: https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
Discussed on HN: https://news.ycombinator.com/item?id=49017344
- 1a527dd5
This is what I like to call performative performance programming. I _LOVE_ performance as much as the next guy. And build times should be as close to 0 seconds as possible.
But this is approaching diminishing returns and I guarantee that your CURRENT bottleneck is not build times.
- christophilus
Bun, but managed by someone who values code quality? Sign me up. It’s a Herculean task, though.