7 ms·
Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
- christophilus 2mo agoBun, but managed by someone who values code quality? Sign me up. It’s a Herculean task, though.
- koolba 2mo ago> It’s a Herculean task, though. I believe it’s spelled Sisyphean.
- _bent 2mo agothe fifth labour of Hercules was cleaning the Augean stables, which this undertaking seems very much alike
- ModernMech 2mo agoBut Hercules eventually finished, I think what koolba is saying is this task can't be finished.
- all2 2mo agoIs one ever truly finished rebuilding an entire code-base one piece at a time?
- jazzzooo 2mo agoThank you! Yes it will be a lot of work. But it will only get easier.
- Retr0id 2mo ago> 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?
- childintime 2mo agoAs 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.
- titularcomment 2mo agoThis 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.
- childintime 2mo agoAI 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.
- hiccuphippo 2mo ago>AI will become the repository owner So Open Source transitions to Public Domain.
- hombre_fatal 2mo agoYou're way ahead of the folks here and they've made you pay for it. Yeah, with AI you can just fork code, get a fix/feature added, and then have AI fold back in changes if you even care about them. Maybe people didn't realize you meant that the collective effort of human maintainers is what's dying? As AI gets better it becomes even more trivial to drive a project. The idea of bike-shedding with other people or campaigning to get in some feature that's critical to you becomes pointless. Just last month I forked libghostty to have AI implement some features I wanted for my personal terminal project, then last week I started getting AI to build me my own terminal engine in Swift. It came up with its own smart architecture like splitting the execution plan vs render as pty feeds come in, and many other nice things I wouldn't have had the foresight to consider on day 1 had I started the project myself. Not to mention it would have taken me many months of time I don't have. Granted, it's a week of daily work to get it to a point where I'd use it, and probably another week of polish to where I'd swap libghostty for it. Especially with my slower AI workflow that guarantees robust, well-designed code. But I've written no code, the writing is on the wall, and this is the worst AI will ever be.
- fg137 2mo agoVery 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.
- ForHackernews 2mo agoWhat'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.
- fg137 2mo agoDeno doesn't seem to have as much momentum ever since Bun showed up, and there is concern about the status of the company. I doubt anyone wants to rely on Deno at this time. Node.js has come a long way, and its support for TS is fairly good these days. Of course it's not an "all-in-one" experience, but I really don't know if it matters. Setting up a bundler is easier than ever, and for complex/niche use cases, you'll likely need webpack instead of whatever comes with Bun. Let alone all the other options that take care of the entire build toolchain. Choosing a runtime just for the tools it brings isn't as good a decision it seems.
- andsoitis 2mo ago> Bun users who don't care about slop will continue to use Bun What slop does Bun create or cause?
- adithyassekhar 2mo agoBun is the slop
- andsoitis 2mo agoWhy do you say Bun is the slop? Does it lack utility?
- deleted 2mo ago[deleted]
- rishav_sharan 2mo ago[flagged]
- fp64 2mo agoI don't see the irony? LLMs are much better at cleaning up a mess. Using LLMs not properly created that mess in the first place.
- fg137 2mo agoThis 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.
- wsdn 2mo ago> 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.
- maccard 2mo agoI’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.
- figmert 2mo agoThey can. You just have to steer them
- maccard 2mo agoCan you share a transcript of an LLM generated feature/bug fix that you steered into being good quality?
- onlyrealcuzzo 2mo agoI'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).
- arendtio 2mo agoWhy is there so much buzz around bun? Can't we just go back to node + npm + vitest + vite?
- rapind 2mo agoAt this point, I'm not sure anyone should still be using npm.
- deleted 2mo ago[deleted]
- quantummagic 2mo agoSeriously. The only way to use it is to be a very religious person. You have to pray every single time you use it that your system doesn't become compromised.
- andyfleming 2mo agoThere’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 https://nubjs.com
- kachnuv_ocasek 2mo agoWhat are the benefits, though?
- kristoff_it 2mo agoTo 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.
- dtj1123 2mo agoAfter 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. The fact that a one-man team achieved 1s build times proves pretty conclusively that slow build times were entirely result of negligent development practices, and that the fork was a complete misallocation of time.
- skeledrew 2mo agoA significant part of the port was also for the built-in safety. Unsafe code just... fails to compile. Turns out there's a journey here.
- Philip-J-Fry 2mo agoThe port was line for line and full of unsafe code. It didn't prevent any bugs. They're not using Rust for its strengths.
- skeledrew 2mo agoYou should give the article[0] a read. "A large percentage of bugs from that list are use-after-free, double-free, and "forgot to free" in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide." "At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomatic Rust, but we are going to continue using C & C++ libraries like JavaScriptCore so it will always have more unsafe than pure Rust projects." [0] https://bun.com/blog/bun-in-rust https://bun.com/blog/bun-in-rust
- mintflow 2mo agosaw 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
- robertlagrant 2mo ago> 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?
- asibahi 2mo agoThe Zig compiler compiles lazily and does not detect dead code. (Read: functions that are not called from any compiled functions)
- robertlagrant 2mo agoThat 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.
- dnautics 2mo agohard to detect. what if a whole code branch is used by macos and you're on x86?
- robertlagrant 2mo agoI don't understand - wouldn't this be observable by the person making the change? They used to call this function / use this class and now they don't any more? Even if it's inside a conditional compilation block.
- wmedrano 2mo agoThe hard to detect is the compilers technical reason for not doing the analysis. Maybe it will one day. In practice, it's annoying to track if those small util functions become dead code.
- 1a527dd5 2mo agoThis 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.
- kristoff_it 2mo agoThe 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-for-the-zig-compiler-this-week 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.
- nextaccountic 2mo ago> TLDR; The Zig compiler takes about 1 minute and 30 seconds to compile debug builds of Bun. Zig's language server doesn't do basic things like type-checking, so often have to run the compiler to see if my code works. 90 seconds to less than 1 second. That's astonishing
- jazzzooo 2mo agoI expect it to drop to 300ms once it no longer relies on Mold for linking. Zig's experimental linker can just modify the binary in place.
- brabel 2mo agoIt’s not so astonishing when you mention that incremental compilation has been only recently added to Zig and is still experimental. This astonishing change, if I understand it correctly, is achieved simply by migrating to the latest version of Zig and enabling this experimental feature.
- ksec 2mo ago>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.
- k3vinw 2mo agoShould have called it Bunz!
- 999900000999 2mo agoHere’s my idea. DinnerRoll Bun in D! If someone with an MBA wants to raise capital we can start next Tuesday!
- dash2 2mo agoI'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....
- jazzzooo 2mo ago[dead]
- rednafi 2mo agoNow 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.
- aizk 2mo agoPerformative programming
- mahdigmk 2mo agoWe are soooo back
- paxys 2mo agoWouldn't be JavaScript without a new flavor of the month runtime or framework.
- deleted 2mo ago[deleted]
- jhack 2mo ago> 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.
- sausagefest 2mo agoStop forking bun. Use regular Node.js. Then making something people want.
- dmix 2mo ago> 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?
- jazzzooo 2mo agoOver 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?
- dmix 2mo agoI don't contribute to open source projects often but deleting dead code has never been a big priority in any project I've worked on unless it's creating real technical debt or it's something easy clean up as part of a bigger migration (similar to what you did here). The point is you had time to look at that stuff and take the risk of deleting it while big projects have a hundred other priorities on Github Issues and customer complaints.
- z0ltan 2mo ago[dead]
- softwaredoug 2mo agoThis 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
- QuercusMax 2mo agoI 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.
- brabel 2mo ago> 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.
- dofm 2mo agoAnd people think there won't be enough demand for AI companies to IPO. All they have to do is start an LLM-driven bun fight.
- evertheylen 2mo agoAlso 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-zig-0-16/16734 https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z... Discussed on HN: https://news.ycombinator.com/item?id=49017344 https://news.ycombinator.com/item?id=49017344
- listic 2mo ago> modern Zig Do they mean more modern than the latest tagged release, 0.16.0, released April 14, 2026?
- searealist 2mo agoThank god this is written in modern Zig and not Zig88.
- tcper 2mo agojackie chan meme
- saurabhmudradi 2mo agoThis just made the bun team work harder on the weekends lol
- pjjpo 2mo agoI maybe am reading too much into this, but it's weird to me that a zig lead would be posting about an AI-only project despite zig's stance on AI. Maybe zig's official stance isn't that well supported in their own community.
- sharts 2mo agowhat is this obsession with bun and js in general? with all this vibe coding why not fix the reasons we needed js in the first place