Live data from Hacker News

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

ziggit.dev

101–110 of 202 posts

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

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

Why? Is fewer things always better? How far should it be consolidated? Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better?

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

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

You have to treat it like a co-worker send you PRs for review. You review, ask to improve/cleanup stuff and it'll follow up. You can even ask it to remember so it follows the patterns in future. Even better, if you work with it to come up with a design first and then send it coding, you often don't need as much cleanup as the desired architecture is agreed upon early.

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

#103

Earlier quoted context omitted.

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.

That may have been the case for the initial iteration a few months ago, but is it still true?

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

#104

Earlier quoted context omitted.

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.

They turned every hidden memory safety bug into a grep'able memory safety bug. That's step 1 and a massive win.

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

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

Well, do one thing an one thing good as in Unix philosophy?

- Runtime

- Package manager

- Test runner

- Build tool

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

#106
post #14

Earlier quoted context omitted.

At this point, I'm not sure anyone should still be using npm.

Seriously. The only way to use it is to be a very religious person. You have to pray every single time you use it that your system doesn't become compromised.

But isn't this a problem with the ecosystem and not with the program? I mean, with yarn / etc., you have the same problems, don't you?

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

#107

Earlier quoted context omitted.

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.

You should give the article[0] a read. "A large percentage of bugs from that list are use-after-free, double-free, and "forgot to free" in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide." "At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,00…

That one’s interesting to me because it speaks to both sides of the debate. Yes, safe Rust is good for catching those kinds of errors at compile time. But also, it should theoretically be very easy for a compiler to avoid those problems in Zig, too, if you are using the language the way it wants to be used.

Which, from what I’ve experienced so far, does seem to take a whole lot more effort if you’re using a coding agent. I spend an incredible amount of time making sure mine doesn’t bloat our codebase with Java-flavored Python, and all the noise and defects and performance problems that it brings.

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

#108
post #93
post #70

Earlier quoted context omitted.

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…

> 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. My experience has been the opposite. I prompt it and it generates something that mostly works, but steering it into something that would actually be maintainable is an exercise in futility. GPT-5.5 uses up my enti…

> I've yet to find a way to get an LLM to actually follow the instructions in CLAUDE/Agents.md

I'll give you a hint: do you rely on people to do the right things, or do you have automated unit, integration, and e2e testing? Do you have linters? Do you have static analysis that automatically runs and will block when violated?

If you are verifying humans, why aren't you verifying LLMs?

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

#109
post #3

> I don’t think any human should sacrifice their sanity untangling this mess of 600K lines of slop code. For that reason, I will not be accepting any human-coded contributions until I deem the project to be in a sane enough shape. Very funny to see a "no humans allowed" contribution policy, and the absurd part is that the rationale actually makes sense. I'm interested to see where this goes. Is it possible to "deslop…

As AI will only get better, accepting contributions can also be automated. The tendency is that open source will die as a collective effort, except for some hardcore stakeouts. AI will become the repository owner. The rest of us just doesn't care enough. This puts users in control.. just pay and you get your feature in a version generated just for you.

You're way ahead of the folks here and they've made you pay for it.

Yeah, with AI you can just fork code, get a fix/feature added, and then have AI fold back in changes if you even care about them.

Maybe people didn't realize you meant that the collective effort of human maintainers is what's dying? As AI gets better it becomes even more trivial to drive a project. The idea of bike-shedding with other people or campaigning to get in some feature that's critical to you becomes pointless.

Just last month I forked libghostty to have AI implement some features I wanted for my personal terminal project, then last week I started getting AI to build me my own terminal engine in Swift.

It came up with its own smart architecture like splitting the execution plan vs render as pty feeds come in, and many other nice things I wouldn't have had the foresight to consider on day 1 had I started the project myself. Not to mention it would have taken me many months of time I don't have.

Granted, it's a week of daily work to get it to a point where I'd use it, and probably another week of polish to where I'd swap libghostty for it. Especially with my slower AI workflow that guarantees robust, well-designed code. But I've written no code, the writing is on the wall, and this is the worst AI will ever be.

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

#110

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.

i did not say "Impossible to detect"!

in practice the exponential explosion of options may become intractable. lets say you have 10 compilation flags with 10 options each. not syre you want the compiler scanning through all that on each pass

Post reply on HN