Live data from Hacker News

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

ziggit.dev

31–40 of 202 posts

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

#31
post #18

Bun, but managed by someone who values code quality? Sign me up. It’s a Herculean task, though.

> 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

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

#32
saw 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

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

#33
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 is the present and future, willingly or not.

Engineering is about design and plan and architectural integrity and qa. Not writing code anymore.

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

#34
post #5

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

> Bun users who don't care about slop will continue to use Bun

What slop does Bun create or cause?

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

#35
post #24
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.

LLMs are as good as the operator directing them.

I'd say as thorough rather than good.

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.

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

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

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

#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've just never noticed?

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

#38

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

Node is too slow, plain and simple.

I've experimented a lot with all nodes up to 24 latest and bun has consistently led to sizeable speed ups.

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

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

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