Live data from Hacker News

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

ziggit.dev

21–30 of 202 posts

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

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

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

#23
post #22
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.

They can. You just have to steer them

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

#25
post #21

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

> Can't we just go back to node + npm + vitest + vite? The mere enumeration shows how bad it is.

I think it's a pretty reasonable split of responsibilities, and not uncommon.

Eg: JDK + maven + junit + tomcat

Making these components pluggable is arguably how we get innovation (eg: yarn/pnpm, jest/vitest, etc)

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

#26

Earlier quoted context omitted.

There’s a project Nub that is meant to bring the benefits of bun to node, which you might appreciate. It also may articulate that gap as to why people like using bun. https://nubjs.com

What are the benefits, though?

This:

    node + npm + vitest + vite
Turns into:

    bun
That's the benefit

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

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

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

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

#28

Earlier quoted context omitted.

There’s a project Nub that is meant to bring the benefits of bun to node, which you might appreciate. It also may articulate that gap as to why people like using bun. https://nubjs.com

What are the benefits, though?

With Bun, I have a single dependency which gives me: bundling, runtime, package management, test runner, SQLite, Postgres connectivity, S3 utilities, sane APIs (compare Bun.serve to whatever the heck I had to do in Node), routing…

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.

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

#29
post #26

Earlier quoted context omitted.

What are the benefits, though?

This: node + npm + vitest + vite Turns into: bun That's the benefit

Throwing out a couple more benefits: bun is faster than node, dramatically so in some specific cases (websockets). Bun also has been doing a great job at building out core libs that probably don't make sense for node, such as the native inbuilt sqlite module, thereby reducing your dependency graph.

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)

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

#30
post #22
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.

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

Post reply on HN