Bun, but managed by someone who values code quality? Sign me up. It’s a Herculean task, though.
Thank you! Yes it will be a lot of work. But it will only get easier.
Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
151–160 of 202 posts
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#152I'd also like to see a (kind of) opposite approach: a fork of zig using only AI contributions. This is more as conceptual art or an experiment, rather than because I strongly support AI. But it would be fun to see how the two projects evolved....
[dead]
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#153> 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.
I came here to post the same thing. But this is addressed later in the same paragraph: > But hopefully better development practices, with a human in the driver’s seat, and a focus on reducing technical debt and writing idiomatic Zig, mean that in a few weeks or months there will be a presentable codebase that serves as a drop-in replacement for Rust Bun 1.4.0. So the intention here is simply more steering. Or perhaps…
[dead]
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#154Earlier quoted context omitted.
GP is talking about the fork of the Zig compiler, not the rewrite of Bun into Rust. Anthropic submitted to patch the Zig compiler to improve Bun compilation times, it was rejected. One reason it was rejected is that it contained AI-generated code, which is against the community guidelines, but more importantly, it would have been rejected regardless of AI use. They claimed a 4x improvement, something like going from…
Is there anything suggesting that Bun even attempted to submit their Zig patches? As far as I know, they were stuck 2 versions behind. With the amount of changes and Zig already working on incremental I'm not sure what the point would have been.
Yes it was never attempted, the whole communication on social media about the AI policy was completely detached from the reality of the engineering work being done on either side.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#155Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#156To 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.
After the all the noise surrounding the forking of the Zig compiler in order to speed up builds, I'm really surprised that this isn't the top comment. The fact that a one-man team achieved 1s build times proves pretty conclusively that slow build times were entirely result of negligent development practices, and that the fork was a complete misallocation of time.
The port was a political decision. It's now the runtime for claude code first and it must align itself in that ecosystem by becoming fully vibe code.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#157Very interesting, but without an ecosystem I doubt this person can keep maintaining it long term. Bun users who don't care about slop will continue to use Bun, those who care will go back to Node.js, and there isn't much left for this project. It is a gigantic task to maintain a JS runtime and add features.
What's the situation with Deno these days? I care about having a fast/secure/modern JS environment and I've been burned by node.js in the past. I'm not that optimistic for Bun with all the recent churn/slopcoding but the pitch of "use this one good TS tool for everything" is appealing.
Deno doesn't seem to have as much momentum ever since Bun showed up, and there is concern about the status of the company. I doubt anyone wants to rely on Deno at this time.
Node.js has come a long way, and its support for TS is fairly good these days. Of course it's not an "all-in-one" experience, but I really don't know if it matters. Setting up a bundler is easier than ever, and for complex/niche use cases, you'll likely need webpack instead of whatever comes with Bun. Let alone all the other options that take care of the entire build toolchain.
Choosing a runtime just for the tools it brings isn't as good a decision it seems.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#158Earlier quoted context omitted.
The port was line for line and full of unsafe code. It didn't prevent any bugs. They're not using Rust for its strengths.
The original Zig code is metaphorically one big unsafe block. Even if the Rust port is made up of 3% unsafe blocks, that still means 97% of the original Zig code has been made safe (in the Rust sense).
Not every line of zig is "unsafe".
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#159Earlier quoted context omitted.
A significant part of the port was also for the built-in safety. Unsafe code just... fails to compile. Turns out there's a journey here.
GP is talking about the fork of the Zig compiler, not the rewrite of Bun into Rust. Anthropic submitted to patch the Zig compiler to improve Bun compilation times, it was rejected. One reason it was rejected is that it contained AI-generated code, which is against the community guidelines, but more importantly, it would have been rejected regardless of AI use. They claimed a 4x improvement, something like going from…
Yep, on rereading my comment I totally failed to make this clear. Cheers.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#160This 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…
I think the only solution is to actually look at the code and ensure that it's not just duplicating logic all over the place and is actually maintainable. Coding models love taking shortcuts to break encapsulation or duplicating things that shouldn't be duplicated.