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.
> 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?
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.
Bun, but managed by someone who values code quality? Sign me up. It’s a Herculean task, though.
I'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....
Why is there so much buzz around bun? Can't we just go back to node + npm + vitest + vite?
>11K deadcode.
How did they end up there? There was another project trying to savage what is left of Zig Bun and turned it into a smaller runtime. I hope may be the project could both work together.
Wouldn't be JavaScript without a new flavor of the month runtime or framework.
> I don’t think any human should sacrifice their sanity untangling this mess of 600K lines of slop code. For that reason, I will not be accepting any human-coded contributions until I deem the project to be in a sane enough shape.
Very funny to see a "no humans allowed" contribution policy, and the absurd part is that the rationale actually makes sense.
I'm interested to see where this goes. Is it possible to "deslop" something of this magnitude?
Performative programming
Here’s my idea.
DinnerRoll
Bun in D!
If someone with an MBA wants to raise capital we can start next Tuesday!
Very 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.
Should have called it Bunz!
We are soooo back
> Bun is the quintessential AI slop project at this point.
To call the Bun rewrite "quintessential slop" is all I need to know to not take this person or their project seriously.
saw another project based on pre-rust bun and this is another one never use bun and sometimes this make me wonder, are we enter a phase the supply way > requirement or people just build stuffs and not care serious usage anymore?
As a software engineer these days, I can't say i do not use Agent to help work done, but i am really a bit of tired to see so much solutions while not talk about what problem they are trying to really solve
Now that no one cares about JS frontend framework, we moved the drama over to JS tooling written in other languages.
One reason I find deno nicer is that the node creator is solid isn't a slopperoo yapping about LLM induced quasi-productivity.
> 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.