> 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?
That makes total sense (though it would be nice if it could do that detected, I suppose), but what makes less sense to me is the accumulation of unnecessary code (and presumably unit tests for that code) that isn't removed as soon as it's no longer needed.
Skilled engineers may still vibe and not care. Beginners may be thorough and experiment and ask till they get the design right even if they don't spot it immediately, just caring does a lot.
Incidentally I’ve always thought that about working on cars, but more like skilled mechanics may still vibe and not care. Amateurs may be thorough but much slower, may need to do a lot of research before every step. Just caring does a lot.
I agree with you about “thoroughness” being key here, but I’d additionally advocate that we need to leave room for people to make some slop learn it.
Part of the learning process, whether you’re a “skilled” or “unskilled” engineer (or not an engineer at all, and noting that going from one to the other is just a matter of learning), is being able to “vibe and not care.” Yes, it’s also helpful to identify things that might not work out theoretically in advance, using the things we learn in our CS programs. But coding with LLMs is a brand new modality, and we are all indeed just learning to work with them.
I think alternating vibe coding with vibe-assisted DRYing/cleaning is ultimately a workflow enhancer that can make better software faster. But engineers have to be allowed to make some slop to learn it.
I'm about to release some tooling that's been very effective for me.
Essentially, there's a few ways LLMs write "bad" code that is different from how people write "bad" code.
We've got pretty good tooling to catch the ways people write bad code - it just happens to be much easier to do with static analysis (and is less noise prone).
The ways LLMs write bad code is typically 1) bad architecture - hard to detect in the ways that are really important, 2) unnecessary state and control flow (and decisions based on state), 3) bad / inadequate tests.
Methods to detect these problems have existed for ages, but they've never caught on because it's typically too difficult to tune them to have high signal / noise for humans, and AFAIK - no one else tried putting them all together and seeing how LLMs work with it.
LLMs are great at sorting through signal / noise -> so you can help surface potential issues with metrics that would be too noisy for humans, but seems to work pretty well for LLMs to find the source of architectural problems and design better solutions (from my experience - may be biased, I built the tooling to literally solve this problem for the main project I'm working on).
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.
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.
The people who originally worked on Bun themselves would disagree with your point (but their situation was based on the premise that they did not take the steps required to leverage incremental compilation): https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...
And, unrelated to Bun, I too would disagree. You don't want to have to wait minutes for a build to complete before you can run the test suite, or even just know if there was a semantic error in your code. Build times are 100% a bottle neck for big-enough projects.
There’s a project Nub that is meant to bring the benefits of bun to node, which you might appreciate. It also may articulate that gap as to why people like using bun.
With Bun, I have a single dependency which gives me: bundling, runtime, package management, test runner, SQLite, Postgres connectivity, S3 utilities, sane APIs (compare Bun.serve to whatever the heck I had to do in Node), routing…
Basically, Bun is giving us something between Rails and the .Net framework for Typescript. It’s become an (almost) standalone runtime for running low-dependency apps.
I rather replace bun with deno, given that now both bun and deno are written in Rust, and Deno have even more node compatibility than bun. Deno and Node both runs on V8, while Bun runs on JSC, and Deno has a killer feature that you don't have to even run npm install to use package, you can just top-level import or await import an URL (given that you allowed it with a command prompt or bypass it competely with -A but discouraged).
I've used Deno, CucumberJS and Playwright to write E2E test suites. Zero npm install and not even deno.json or package.json
Throwing out a couple more benefits: bun is faster than node, dramatically so in some specific cases (websockets). Bun also has been doing a great job at building out core libs that probably don't make sense for node, such as the native inbuilt sqlite module, thereby reducing your dependency graph.
People shit on the node/npm ecosystem relentlessly for the typical inauditable deep dependency graph, and bun makes substantial improvements to that situation.
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.
> 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?
As AI will only get better, accepting contributions can also be automated.
The tendency is that open source will die as a collective effort, except for some hardcore stakeouts. AI will become the repository owner. The rest of us just doesn't care enough.
This puts users in control.. just pay and you get your feature in a version generated just for you.
This does anything but put the user in control. I also think that arbitrary new features on established platforms are not in any close future as it already burns many tokens for you to instruct your agent to fork something and add x, y, z.
AI will improve more rapidly than you imagine it will. Open source has been built around rituals that will go the way of the LP: for the nostalgic enthusiast only. This project already shows nobody cares enough now, let alone a year from now.
AI is already better than 90% of my colleagues, and none of them can write an exploit, or instantly draw on the breadth of information it can. So all they do is chaperone. Well, that will be gone too in a few years. What will remain are example repositories that serve as the starting point to add your own special feature. The curated set may well become private again, as a competitive advantage.
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
This is a personal pursuit from what I can tell. I wouldn't use any opinion or judgment from this person to reach any conclusion about "the Zig community". This is just unnecessary.
If this person can stick to these goals and keep maintaining the project (which I do highly doubt), I don't see how this can possibly be a bad thing.
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.
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. This proves pretty conclusively that slow build times were entirely result of negligent development practices, and that the fork was a complete misallocation of time.
This is astonishing. Is anyone else surprised at this dead code figure? Is it a feature of large projects I've just never noticed?
So we're using LLMs to clean up the code that LLMs ruined in the first place? We’ve reached peak tech in 2026.
Skilled engineers may still vibe and not care. Beginners may be thorough and experiment and ask till they get the design right even if they don't spot it immediately, just caring does a lot.
Part of the learning process, whether you’re a “skilled” or “unskilled” engineer (or not an engineer at all, and noting that going from one to the other is just a matter of learning), is being able to “vibe and not care.” Yes, it’s also helpful to identify things that might not work out theoretically in advance, using the things we learn in our CS programs. But coding with LLMs is a brand new modality, and we are all indeed just learning to work with them.
I think alternating vibe coding with vibe-assisted DRYing/cleaning is ultimately a workflow enhancer that can make better software faster. But engineers have to be allowed to make some slop to learn it.
Essentially, there's a few ways LLMs write "bad" code that is different from how people write "bad" code.
We've got pretty good tooling to catch the ways people write bad code - it just happens to be much easier to do with static analysis (and is less noise prone).
The ways LLMs write bad code is typically 1) bad architecture - hard to detect in the ways that are really important, 2) unnecessary state and control flow (and decisions based on state), 3) bad / inadequate tests.
Methods to detect these problems have existed for ages, but they've never caught on because it's typically too difficult to tune them to have high signal / noise for humans, and AFAIK - no one else tried putting them all together and seeing how LLMs work with it.
LLMs are great at sorting through signal / noise -> so you can help surface potential issues with metrics that would be too noisy for humans, but seems to work pretty well for LLMs to find the source of architectural problems and design better solutions (from my experience - may be biased, I built the tooling to literally solve this problem for the main project I'm working on).
Engineering is about design and plan and architectural integrity and qa. Not writing code anymore.
If you were an L6+, it was already not really about that.
It's kind of amazing to me that people think the only thing engineers do and the only value they bring is writing code.
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.
But this is approaching diminishing returns and I guarantee that your CURRENT bottleneck is not build times.
And, unrelated to Bun, I too would disagree. You don't want to have to wait minutes for a build to complete before you can run the test suite, or even just know if there was a semantic error in your code. Build times are 100% a bottle neck for big-enough projects.
DinnerRoll
Bun in D!
If someone with an MBA wants to raise capital we can start next Tuesday!
I believe it’s spelled Sisyphean.
https://nubjs.com
Basically, Bun is giving us something between Rails and the .Net framework for Typescript. It’s become an (almost) standalone runtime for running low-dependency apps.
I've used Deno, CucumberJS and Playwright to write E2E test suites. Zero npm install and not even deno.json or package.json
People shit on the node/npm ecosystem relentlessly for the typical inauditable deep dependency graph, and bun makes substantial improvements to that situation.
The mere enumeration shows how bad it is.
Eg: JDK + maven + junit + tomcat
Making these components pluggable is arguably how we get innovation (eg: yarn/pnpm, jest/vitest, etc)
I've experimented a lot with all nodes up to 24 latest and bun has consistently led to sizeable speed ups.
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.
What slop does Bun create or cause?
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?
The tendency is that open source will die as a collective effort, except for some hardcore stakeouts. AI will become the repository owner. The rest of us just doesn't care enough.
This puts users in control.. just pay and you get your feature in a version generated just for you.
AI is already better than 90% of my colleagues, and none of them can write an exploit, or instantly draw on the breadth of information it can. So all they do is chaperone. Well, that will be gone too in a few years. What will remain are example repositories that serve as the starting point to add your own special feature. The curated set may well become private again, as a competitive advantage.
So Open Source transitions to Public Domain.
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
If this person can stick to these goals and keep maintaining the project (which I do highly doubt), I don't see how this can possibly be a bad thing.
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.