Live data from Hacker News

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

ziggit.dev

71–80 of 202 posts

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

#71
post #57

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.

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

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

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

#72
post #31
post #18

Earlier quoted context omitted.

> 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

But Hercules eventually finished, I think what koolba is saying is this task can't be finished.

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

#73

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

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.

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

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

You have no idea, to slop-circle is getting more common.

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.

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

#75

Earlier quoted context omitted.

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.

you'd be amazed how many do just that and are incredibly bad at anything else that does not involve opening up an IDE that spoon feeds them everything they need.

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

#76
post #57

Earlier quoted context omitted.

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

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

The port was line for line and full of unsafe code. It didn't prevent any bugs. They're not using Rust for its strengths.

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

#77
post #27
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.

You should see the error bars between human programmers.

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

#78

Earlier quoted context omitted.

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.

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

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

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

This was always the plan. Code is no longer written by humans, code is LLLM output of broken slop that is mostly software-shaped, impossible for humans to read and make sense of it (because it makes no sense). So the only solution is that all code is intended to be read and written by machines. The human-in-the-loop era was always a stopgap.

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

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

Yeah, good luck with that one though. LLMs are terrible at deslop, or they wouldn't slop in the first place.
Post reply on HN