Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Should have called it Bunz!by k3vinw
- Thank god this is written in modern Zig and not Zig88.by searealist
- Also highly relevant project: Cruller, also uses the pre-rewrite Bun codebase but focuses only on the runtime part for production.
Link: https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
Discussed on HN: https://news.ycombinator.com/item?id=49017344
by evertheylen - > 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?
by Retr0id - 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.
by childintime - Why is there so much buzz around bun? Can't we just go back to node + npm + vitest + vite?by arendtio
- node is used in prod and bun is faster than node. so using bun directly translates to lower cogsby rk06
- Every new framework gets buzz on HN and is forgotten a day later. Meanwhile 99% of developers never left node + npm + vite in the first place.by paxys
- At this point, I'm not sure anyone should still be using npm.by rapind
- 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.
by epolanski - > Can't we just go back to node + npm + vitest + vite?
You're kind of stating the reason for the buzz there: one runtime that does everything you need rather than cobbling together a dozen different tools.
Not that there's a problem cobbling together different tools made to do a job, each tool has a purpose and solves a problem, but having all problems solved out of the box is very convenient.
Bun does offer an additional major advantage, i.e. the bundler has a runtime API, so the same process that serves your assets can also bundle them in memory without having to coordinate an external bundler writing static files to disk.
by root_axis - >Can't we just go back to node + npm + vitest + vite?
The mere enumeration shows how bad it is.
by coldtea - 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.by andyfleming
- Breaking: JavaScript developers create three new frameworks/kits while you were reading this sentence.by virajk_31
- 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.
by 1a527dd5 - No. Fast builds are a must for a project like this, in my opinion. This is an important step towards making the project easier to maintain.
- 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.
by kristoff_it - 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.by jazzzooo
- > It’s a Herculean task, though.
I believe it’s spelled Sisyphean.
by koolba - > 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.
How long has this person been programming?
by dmix - Over a decade. I should've clarified, I meant "trivially dead" code that's not called by anything. Can you think of another project with that much?by jazzzooo
- 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
by softwaredoug - 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.by QuercusMax
- > You sort of did this pre-AI
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.
by brabel - > 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?
- It's less than I'd expect, given how Bun was developed. I'm sure there's plenty more of that to be had in that codebase.
- I'm astonished that anyone is astonished by this amount of dead code in any large code-base. That's like 10 somewhat normal sized PRs worth of code.by ryan_lane
- The Zig compiler compiles lazily and does not detect dead code. (Read: functions that are not called from any compiled functions)by asibahi
- At my last company I cut 8k lines from a 10k component and fixed every major bug in the process. It wasn't "dead" per se, but if you start by cleaning up one little bad abstraction then that opens opportunities for the next one and the one after that till eventually all you're left with is software which actually does what it's supposed to.
That hasn't been a unique experience either -- quite the opposite. Codebases bloat over time. The only thing astonishing to me is that in something as large as Bun they only found 11k lines.
by hansvm