> 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?
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.
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.
This is an example of technical problems being easy but organization being hard imo. It is stupid if you think about it from a theoretical perspective but they didn’t want to use this feature for some reason.
Probably because they did their fork of zig for fast compilation before and they didn’t want to just discard it and use this
Do the caveats mean that it could _not_ actually have had fast builds on all the platforms it supports? (Honestly asking if I connected the dots correctly here, this is not a snarky "actually" rethorical question...)
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
> 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.
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.
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....
> 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.
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
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.
No, I did the opposite. First refactor the code base to make a new feature fit naturally in it later on. Then hopefully the new feature is easy to implement cleanly and correctly first time.
The only times I’ve had to go back and do things again “properly” was when the feature itself was not designed properly or didn’t fit at all even after I tried to adapt it to fit which happens rarely, and mostly for experimental things that no one knows exactly how they should work.
39 comments
[ 0.19 ms ] story [ 51.2 ms ] threadVery 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?
So we're using LLMs to clean up the code that LLMs ruined in the first place? We’ve reached peak tech in 2026.
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.
Probably because they did their fork of zig for fast compilation before and they didn’t want to just discard it and use this
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
This is astonishing. Is anyone else surprised at this dead code figure? Is it a feature of large projects I've just never noticed?
But this is approaching diminishing returns and I guarantee that your CURRENT bottleneck is not build times.
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.
DinnerRoll
Bun in D!
If someone with an MBA wants to raise capital we can start next Tuesday!
One reason I find deno nicer is that the node creator is solid isn't a slopperoo yapping about LLM induced quasi-productivity.
To call the Bun rewrite "quintessential slop" is all I need to know to not take this person or their project seriously.
Use regular Node.js.
Then making something people want.
How long has this person been programming?
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
No, I did the opposite. First refactor the code base to make a new feature fit naturally in it later on. Then hopefully the new feature is easy to implement cleanly and correctly first time. The only times I’ve had to go back and do things again “properly” was when the feature itself was not designed properly or didn’t fit at all even after I tried to adapt it to fit which happens rarely, and mostly for experimental things that no one knows exactly how they should work.