> 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?
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.
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.
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'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).
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.
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.
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.
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 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.
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?
The Zig compiler compiles lazily and does not detect dead code. (Read: functions that are not called from any compiled functions)
> 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.
Well so far we've been using humans to clean up the code that humans ruined in the first place, it's hardly a logical fallacy
LLMs are as good as the operator directing them.
The error bars on that one are too large to fit on screen, but yes.
I'd say as thorough rather than good.
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.
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.
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’d say I fall in the “AI skeptic but willing to use it” category. If LLMs can actually clean up after themselves it would actually be a game changer.
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).
You forgot to include link to your tool.
They can. You just have to steer them
This is the present and future, willingly or not.
Engineering is about design and plan and architectural integrity and qa. Not writing code anymore.
> 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.
Here’s my idea.
DinnerRoll
Bun in D!
If someone with an MBA wants to raise capital we can start next Tuesday!
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.
>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.
Bun, but managed by someone who values code quality? Sign me up. It’s a Herculean task, though.
> It’s a Herculean task, though.
I believe it’s spelled Sisyphean.
the fifth labour of Hercules was cleaning the Augean stables, which this undertaking seems very much alike
Why is there so much buzz around bun? Can't we just go back to node + npm + vitest + vite?
Breaking: JavaScript developers create three new frameworks/kits while you were reading this sentence.
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.
https://nubjs.com
What are the benefits, though?
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.
This:
Turns into: That's the benefitI 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
To say nothing of `bun install` being about 50 times faster than npm, and disabling most post-install hooks by default.
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.
At this point, I'm not sure anyone should still be using npm.
>Can't we just go back to node + npm + vitest + vite?
The mere enumeration shows how bad it is.
I think it's a pretty reasonable split of responsibilities, and not uncommon.
Eg: JDK + maven + junit + tomcat
Making these components pluggable is arguably how we get innovation (eg: yarn/pnpm, jest/vitest, etc)
Node is too slow, plain and simple.
I've experimented a lot with all nodes up to 24 latest and bun has consistently led to sizeable speed ups.
Should have called it Bunz!
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.
What if adding features wasn't the scope and just providing a fast and memory efficient runtime that doesn't pretend to be everything at once.
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.
> Bun users who don't care about slop will continue to use Bun
What slop does Bun create or cause?
Bun is the slop
Why do you say Bun is the slop? Does it lack utility?
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 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.
>AI will become the repository owner
So Open Source transitions to Public Domain.
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.