Live data from Hacker News

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

ziggit.dev

111–120 of 202 posts

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

#111

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.

The original Zig code is metaphorically one big unsafe block. Even if the Rust port is made up of 3% unsafe blocks, that still means 97% of the original Zig code has been made safe (in the Rust sense).

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

#112
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…

Can you elaborate on the tests thing? I'm new to testing, and AI agents recently voluntarily added an large number of tests to one of my projects. I've been learning a lot by reading them, and it seems like a great habit to develop.

But they're also writing some very strange code and some very strange tests. I don't know what good practices look like here, so when something looks strange to me I can't trust my own judgment, whether it's actually smelly or just a pattern I'm not used to yet.

--

On a side note, I recently had an agent implement a major architectural change. It turned out to have done it completely backwards, in a way that was pointless. (Improved nothing and actively made things worse.) However it had supplied generous tests for the new code, and of course all the tests passed...

So it had "proven the correctness" of something which was completely incorrect.

I later realized that even formal verification would not have prevented this. It would have just written a mathematical proof that the wrong code was correct.

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

#114
post #21

Earlier quoted context omitted.

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

Is this the old monolith vs micro-services argument?

I guess this boils down to 'how granular and function specific are your building blocks?' and where you draw the lines programmatically: library interfaces in a single program/executable, API/ABI between two or more programs/executables, HTTP API/other transport protocol across network boundaries between two or more programs/executables, and so on.

I'm not sure I'm slicing this along the correct abstractions, though.

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

#115

Earlier quoted context omitted.

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

> using the language the way it wants to be used.

This sounds like just the coding conventions dependency they're trying to avoid.

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

#117
post #93

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

Yes, and agents are generating code that fails those checks regularly. I wouldn’t accept a junior engineer saying “oh I just submit my code and see if the tests pass, let me know if they’re failing and I’ll fix them”. Pre commit hooks are disable-able and LLMs have shown they’re more than willing to say “tests were failing before this change” when they weren’t, or to use python scripts to self escape their sandbox restrictions.

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

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

They can. You just have to steer them

Can you share a transcript of an LLM generated feature/bug fix that you steered into being good quality?

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

#120

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

Breaking: JavaScript developers create three new frameworks/kits while you were reading this sentence.

And you're already not getting hired because they're not on your CV.
Post reply on HN