hckrnws
Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
(ziggit.dev)
237
166
by kristoff_it
by kristoff_it
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.
Turns out there's a journey here.
So we're using LLMs to clean up the code that LLMs ruined in the first place? We’ve reached peak tech in 2026.
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 1.8% feels high if it's trivially dead. When I've run simple static analysis on decent codebases before, it's been much lower. For non-trivial dead code, it might be low. E.g. a lot of projects have piles of "dead" code behind ancient feature flags that would never be switched.
A small amount of dead code is fine. E.g. it might not be worth deleting utility methods that you happen to remove the last use of if they are simple and you might re-add a use later. Generated code is often dead since it's not worth specifying to the generator exactly what will be used. Other times, deleting dead code can lead to a valuable cascade of other deletions and simplifications.
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
How long has this person been programming?
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.
I believe it’s spelled Sisyphean.
[dead]
Link: https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
Discussed on HN: https://news.ycombinator.com/item?id=49017344
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?
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!
Do they mean more modern than the latest tagged release, 0.16.0, released April 14, 2026?
All they have to do is start an LLM-driven bun fight.
To call the Bun rewrite "quintessential slop" is all I need to know to not take this person or their project seriously.
[deleted]
Use regular Node.js.
Then making something people want.
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
[dead]
[dead]
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.
One reason I find deno nicer is that the node creator is solid isn't a slopperoo yapping about LLM induced quasi-productivity.
[deleted]
Anthropic submitted to patch the Zig compiler to improve Bun compilation times, it was rejected. One reason it was rejected is that it contained AI-generated code, which is against the community guidelines, but more importantly, it would have been rejected regardless of AI use. They claimed a 4x improvement, something like going from 2 minutes to 30 seconds, but, according to the Zig team, it made compilation non-deterministic, and missed on the real improvement they worked on, which was sub-1s incremental builds.
"Buz" shows that the fork submitted by Anthropic wasn't needed as Bun can now compile under 1s (incrementally), which is much better than the 30s they achieved with their patch.
It is likely that this rejection, especially the "no AI" aspect of it encouraged Anthropic to move away from Zig.
"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."
Blind AI hatred is just insane to me and it goes against the spirit of HN, we're not supposed to just go "ITS BAD CODE" here, we are supposed to have actual engaging conversations. Too much of HN devolves into "ITS SLOP" instead of "Hey, I know you're leaning on the AI a bit, but here's what's wrong with the code: ...." which would be more constructive and fall better in line with what I've expected from HN and seen for years, until recently.
AI fatigue and AI prejudice should not be confused for one another, sure you can have both, but most people who hate AI blindly just have AI prejudice at this point.
I'm generally in agreement, but I think current corporate/productivity culture and AI is a bad mix that makes this quote/sentiment feel impossible. All of the current incentives are set up to push out as much sloppy code as possible, and AI is the perfect machine for doing that in huge quantities, to the point where reviewing all of it is impossible. It's not really AI's fault (imo). There's plenty of ways to use it to design more elegant, understandable, maintainable systems. But unfortunately that's going to take a cultural shift, and part of that cultural shift involves people pushing back against AI as it's used today.
You can make them output what you would've written yourself, but that would be slower than writing it yourself, so no one does that - but it’s trivially true.
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.
The main problem is that pointing an LLM at a codebase and telling it to just "make it better" taps out pretty quickly. That is, not that there's zero juice to squeeze there, but there's not a ton. You can get a bit of improvement but it also rapidly starts changing things just to change things, which I'm not even going to complain about all that much because there's a sense in which it is simply doing as you asked.
So you still need human taste and direction. This will be especially true for something the size of that codebase where you can only hold small fractions of the actual code in the context window at once. Summaries only get you so far.
More broadly I've found that making code more elegant (e.g. by removing duplication) increases the cognitive load, because now you can't just read the code anymore but need to mentally "decompress" the higher level structures and indirection into the straight line code, the "code that actually runs."
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).
> But hopefully better development practices, with a human in the driver’s seat, and a focus on reducing technical debt and writing idiomatic Zig, mean that in a few weeks or months there will be a presentable codebase that serves as a drop-in replacement for Rust Bun 1.4.0.
So the intention here is simply more steering. Or perhaps better steering (code structure appears to be a matter of taste... I had a very perplexing chat with a friend yesterday who insisted that four backend processes were required to serve a single HTTP request...)
[dead]
Still ironic, of course.
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.
In 2025, sometimes I decided to put a slop LinkedIn post to ChatGPT (back then) to deslopify.
Now, the slop circle is everywhere.
Your PO uses automations to create tasks? Half of the comments are bot slop? Links to documents never edited or read by another human? A lazy three sentence description of a task requirement you would have gotten previously sounds like a dream. Now everything generates pages long texts and you can't possibly go through the slop without AI agents. You need your agents comb through the slop and demystify the task for you.
Same with the other end... Slop PRs will be reviewed by your agents, hoping you catch 2-3 issues so that you can pretend you did a review. The author didn't do a review on their generated slop, but sure, let's pretend reviewers still review code.
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.
It's bog standard, very mild technical debt.
90 seconds to less than 1 second. That's astonishing
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.
node + npm + vitest + vite
bun
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.
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 guess this boils down to 'how granular and function specific are your building blocks?' and where you draw the lines programmatically: library interfaces in a single program/executable, API/ABI between two or more programs/executables, HTTP API/other transport protocol across network boundaries between two or more programs/executables, and so on.
I'm not sure I'm slicing this along the correct abstractions, though.
- Runtime
- Package manager
- Test runner
- Build tool
Once you get to programming language tooling, "do one thing and do it well" is not necessarily the best course, especially when you get leaking abstractions and limited interoperability and messy choices to make where no tool is standard.
At the worst case you get this: https://xkcd.com/1987/
Doesn't have to be always, it often is however. Imagine how better this would be with fewer things: https://xkcd.com/1987/
>Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better?
Taking it to an extreme, why not?
If it was just a tool that did everything for a language (compile, dependencies, formatting, linting, debug, profile), I'd be totally OK. I'd also be ok with a handful of different tools, all by the same team/project, with the same shared vision and interoperability in mind to begin with.
Go got quite close with that.
[deleted]
I've experimented a lot with all nodes up to 24 latest and bun has consistently led to sizeable speed ups.
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.
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.
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.
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.
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.
What slop does Bun create or cause?
Which, from what I’ve experienced so far, does seem to take a whole lot more effort if you’re using a coding agent. I spend an incredible amount of time making sure mine doesn’t bloat our codebase with Java-flavored Python, and all the noise and defects and performance problems that it brings.
agreed. in my side project im tinkering with a memory safety checker in zig that intercepts a compiler artifact, and it works better with idiomatic zig, problematic code is when you try to write c-isms in zig -- so i basicallt tell the checker to reject c-isms that create ambiguity for safety checking.
This sounds like just the coding conventions dependency they're trying to avoid.
An LLM could probably also trivially give you accurate reviews saying which parts were unsafe and in need of tests or reviews. I mean, considering their LLM budgets they could probably have had nightly reviews running every night for years before spending more than their Rust rewrite.
Not that I think Rust rewrite was a bad idea. Rust is a good fit for this kind of project. I say that as a Zig enthusiast. It’s just that their stated motivation and reported results are kinda BS. If they just wrote “we just like Rust and thought it’d be cool to see of LLM could do the whole rewrite”, and left it at that, I think it’d be a more honest description of the motivation. The rest is just rationalisation.
Welcome to the dev community!
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.
LLMs, to a first approximation, already did as well as they could on the first pass. You can get a bit more out of them by asking them to just try harder, but not much. Whereas if you go in with specific changes they are pretty good at implementing them.
This especially matters because my personal style deviates from the common practices. This may also be why I can't get it to just happen by prompting for it. But if you walk it through it's perfectly capable of transforming the code into a better style, and it's still way faster than trying to write it from scratch.
My experience has been the opposite. I prompt it and it generates something that mostly works, but steering it into something that would actually be maintainable is an exercise in futility. GPT-5.5 uses up my entire allocation of tokens in just reading the context docs and doing a single shot task.
> aven't found a way to prompt it with any number of skills or CLAUDE.mds or anything else to get it to do it the way I want on the first pass, but it's not that hard to just fix it afterwards.
I've yet to find a way to get an LLM to actually follow the instructions in CLAUDE/Agents.md It very quickly gets to a point where it forgets explicit instructions such as "run clang-format on all .h/.cpp files that you touch", and saying "our coding standards can be found at <link to Notion/Confluence>, please ensure all code adheres strictly to this standard" is ignored. I'd also say that the first pass of the code is very often not even close to how it _should_ be implemented so it's not just review and patch up, it's rearchitect + restructure 50% of the code.
> it also rapidly starts changing things just to change things,
Agreed. LLM's are (very good) text generators. They are good for generating code, and left to their own devices they will generate and generate and generate. Getting them to edit, simplify, and foresee future problems is something that people keep saying "use the latest model, it's amazing (despite saying that about the last 3 models" or "you just need to use <harness|framework>" or "your agents.md needs to contain XYZ" will solve.
I've seen others have this experience, too.
It would be interesting to sit us down next to each other for a day or two and compare how we do things, but I suspect much less than that won't reveal much of interest.
It is weird to me how often I have to remind the models about their skills or CLAUDE.md (or equivalent). Though I've sort of taken it as just another way I can impact the process, because sometimes I'm happy for them to forget a particular skill for a moment... particularly when I want it to just do a thing based on my prompt and it decides to invoke the "OK let's design this super carefully" skill. I've gotten a lot of use out of that one but I'm pretty comfortable having to explicitly invoke it.
But they're also writing some very strange code and some very strange tests. I don't know what good practices look like here, so when something looks strange to me I can't trust my own judgment, whether it's actually smelly or just a pattern I'm not used to yet.
--
On a side note, I recently had an agent implement a major architectural change. It turned out to have done it completely backwards, in a way that was pointless. (Improved nothing and actively made things worse.) However it had supplied generous tests for the new code, and of course all the tests passed...
So it had "proven the correctness" of something which was completely incorrect.
I later realized that even formal verification would not have prevented this. It would have just written a mathematical proof that the wrong code was correct.
Something like that.
Too many new nodes in the syntax tree, or a sub-tree that appears sufficiently similar to another sub-tree (for various definitions of similar), data-flow/side effects gets more convoluted, too many LOC, and so on.
But it doesn't yet have a coherent UX unless you're me.
Hopefully, I'll iron that out over the next week and I'll update you.
In practice, it's annoying to track if those small util functions become dead code.
in practice the exponential explosion of options may become intractable. lets say you have 10 compilation flags with 10 options each. not syre you want the compiler scanning through all that on each pass
People shit on the node/npm ecosystem relentlessly for the typical inauditable deep dependency graph, and bun makes substantial improvements to that situation.
Edit: bun recently added an inbuilt api for manipulating images (resize, change formats, etc). Another good example of them adding native/faster functionality that replaces significant dependencies (in this case, likely sharp: https://www.npmjs.com/package/sharp?activeTab=versions)
I've used Deno, CucumberJS and Playwright to write E2E test suites. Zero npm install and not even deno.json or package.json
[deleted]
To try a metaphor: "Why would you grow crops ? Do you lack food on your table ?"
LLMs are prediction engines: you can move the needle (heavily) on the predictions from lazy to correct by construction, but the defaults even on high end models like Opus are always riddled with shortcuts.
LLMs can produce coherent & safe Rust 1.92, LLMs can produce coherent Zig 0.16, but that's dependent on in context learning & instruction following.
Which, ironically, is something I’d love for my browser’s JavaScript runtime to do. But I can also respect others not wanting that.
Do you know what's infinitely cheaper and faster than an LLM running nightly reviews of all of the code and infact mathematically provable that the code (and any new code) is memory safe? It's called the borrow checker.
I'll give you a hint: do you rely on people to do the right things, or do you have automated unit, integration, and e2e testing? Do you have linters? Do you have static analysis that automatically runs and will block when violated?
If you are verifying humans, why aren't you verifying LLMs?