Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

ziggit.dev

Post reply on HN
Print view View original

61–70 of 202 posts

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#61

Post by ryan_lane »

robertlagrant wrote: post #37

> 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'…

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.

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#62

Post by singron »

robertlagrant wrote: post #37

> 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'…

TFA says the whole codebase is 600k, so that would be 1.8% dead code. IME dead code is much more common in larger codebases as figuring out that code is dead becomes more non-local and changes over time create dead code at a distance. I'm also not sure if the 11k was trivially dead (`if (false) { dead_code(); }`) or if it was more subtle (e.g. dynamically-dispatchable code that can't logically be called).

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.

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#65

Post by dnautics »

robertlagrant wrote: post #56
asibahi wrote: post #45

Earlier quoted context omitted.

The Zig compiler compiles lazily and does not detect dead code. (Read: functions that are not called from any compiled functions)

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.

hard to detect. what if a whole code branch is used by macos and you're on x86?

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#66

Post by skeledrew »

adithyassekhar wrote: post #50
andsoitis wrote: post #34

Earlier quoted context omitted.

> Bun users who don't care about slop will continue to use Bun What slop does Bun create or cause?

Bun is the slop

Seems to be good slop, since Claude Code works so well.

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#67

Post by baq »

lionkor wrote: post #27
axod wrote: post #24

Earlier quoted context omitted.

LLMs are as good as the operator directing them.

The error bars on that one are too large to fit on screen, but yes.

Only if you have a tiny screen.

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.

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#68

Post by nextaccountic »

kristoff_it wrote: post #55
1a527dd5 wrote: post #47

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 ev…

> 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

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#69

Post by robertlagrant »

dnautics wrote: post #65
robertlagrant wrote: post #56

Earlier quoted context omitted.

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.

hard to detect. what if a whole code branch is used by macos and you're on x86?

I 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.

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#70

Post by jerf »

maccard wrote: post #22
wsdn wrote: post #12

> 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.

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.

LLMs can clean up after themselves if you steer them. It's not very hard. I often have a two-step dance I do where the LLM first outputs some code and then I prompt it to fix the types up to my standards. I haven'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. It's a fast enough process that it feels fine using it. One can even make a case for it being a decent way to operate anyhow; make a sketch, then firm it up isn't entirely unlike my manual coding process was anyhow.

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.

Post reply on HN