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

81–90 of 202 posts

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

#81

Post by IshKebab »

dtj1123 wrote: post #57
kristoff_it wrote: post #17

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.

I'm pretty sure they forked Zig long before it supported incremental compilation. In fact, it's still experimental and not enabled by default.

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

#82

Post by andai »

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 came here to post the same thing. But this is addressed later in the same paragraph:

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

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

#83

Post by fhd2 »

nullbio wrote: post #80
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.

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

Not entirely my experience. LLMs can be good at two things, but unable to be good at them _at the same time_. I've had some success with getting decent simplification suggestions out of them.

Still ironic, of course.

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

#84

Post by onlyrealcuzzo »

mirekrusin wrote: post #40
onlyrealcuzzo wrote: post #30

Earlier quoted context omitted.

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

You forgot to include link to your tool.

An LLM could probably figure out how to use it now.

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.

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

#85

Post by andai »

jerf wrote: post #70
maccard wrote: post #22

Earlier quoted context omitted.

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

I asked an agent for some high level cleanup and refactoring. I found that I ended up disagreeing with most of the structural changes. Some of them were necessary, some were beneficial, but largely it turned straight line code into abstract factory manager type stuff.

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

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

#86

Post by zdragnar »

robertlagrant wrote: post #69
dnautics wrote: post #65

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.

That requires a person to be making that change. If the change is vibe coded and the person is only checking that the tests pass, it's not hard for cruft to accumulate.

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

#88

Post by all2 »

mirekrusin wrote: post #40
onlyrealcuzzo wrote: post #30

Earlier quoted context omitted.

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

You forgot to include link to your tool.

If I had to do a 'code quality' checker I think I'd try to use some combination of syntax tree analysis, data flow analysis, and LOC changed.

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.

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

#90

Post by paxys »

arendtio wrote: post #13

Why is there so much buzz around bun? Can't we just go back to node + npm + vitest + vite?

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.
Post reply on HN