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

121–130 of 202 posts

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

#121

Post by softwaredoug »

This effort makes me think of the tick-tock oscillation between features and code stewardship I’ve experienced on every agent heavy coding project

Tick: go hard after features, build a correct and extremely messy version

Tock: digest what was done, deslopify, improve project aspects that go beyond feature correctness: performance, maintainability, general fragility / sensitivity to change

My experience is spending a day vibe coding a working application. Then a week unslopifying it to make it a viable software project that can sustainably accept more features without the house of cards collapsing.

You sort of did this pre-AI, but then the professional human coder had a stronger mental model of the system, and IMO was going slower that the switch from tick to tock wasn’t as jarring

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

#122

Post by maccard »

owaislone wrote: post #102
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.

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.

I would tell my co worker “this code has so many issues that I’m not actually reviewing it. Please make sure it meets the project standards before sending it back to me”if it happened twice I’d talk to their manager.

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

#123

Post by owaislone »

maccard wrote: post #122
owaislone wrote: post #102

Earlier quoted context omitted.

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.

I would tell my co worker “this code has so many issues that I’m not actually reviewing it. Please make sure it meets the project standards before sending it back to me”if it happened twice I’d talk to their manager.

Sure - define your project standards in the repo or agent's skill and tell it just that.

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

#124

Post by jerf »

andai wrote: post #85
jerf wrote: 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…

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…

If it wasn't clear, I don't ask the agent to "clean up my code". I ask it to "take this map[string]string you pass around with constant keys and turn that into a structure" or "extract this API provider out into an interface and make everything using it use this interface instead" or other concrete instructions.

LLMs, to a first approximation, already did as well as they could on the first pass. You can get a bit more out of them by asking them to just try harder, but not much. Whereas if you go in with specific changes they are pretty good at implementing them.

This especially matters because my personal style deviates from the common practices. This may also be why I can't get it to just happen by prompting for it. But if you walk it through it's perfectly capable of transforming the code into a better style, and it's still way faster than trying to write it from scratch.

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

#125

Post by audunw »

atombender wrote: post #111
Philip-J-Fry wrote: post #76

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.

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

Since they did a one-to-one translation to start with, hypothetically, if these were the true numbers, you could probably get a static analysis tool to guarantee you that 97% of the zig code was safe and tell you which of the 3% were unsafe. Zig has a lot more syntax and conventions to encourage safe code compare to C after all. It just doesn’t have way to mark which parts are safe or unsafe.

An LLM could probably also trivially give you accurate reviews saying which parts were unsafe and in need of tests or reviews. I mean, considering their LLM budgets they could probably have had nightly reviews running every night for years before spending more than their Rust rewrite.

Not that I think Rust rewrite was a bad idea. Rust is a good fit for this kind of project. I say that as a Zig enthusiast. It’s just that their stated motivation and reported results are kinda BS. If they just wrote “we just like Rust and thought it’d be cool to see of LLM could do the whole rewrite”, and left it at that, I think it’d be a more honest description of the motivation. The rest is just rationalisation.

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

#126

Post by jerf »

maccard wrote: post #93
jerf wrote: 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…

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

I've seen others have this experience, too.

It would be interesting to sit us down next to each other for a day or two and compare how we do things, but I suspect much less than that won't reveal much of interest.

It is weird to me how often I have to remind the models about their skills or CLAUDE.md (or equivalent). Though I've sort of taken it as just another way I can impact the process, because sometimes I'm happy for them to forget a particular skill for a moment... particularly when I want it to just do a thing based on my prompt and it decides to invoke the "OK let's design this super carefully" skill. I've gotten a lot of use out of that one but I'm pretty comfortable having to explicitly invoke it.

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

#127

Post by fg137 »

epolanski wrote: post #41
fg137 wrote: 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.

What if adding features wasn't the scope and just providing a fast and memory efficient runtime that doesn't pretend to be everything at once.

People will move to a different runtime that provides the features they need.

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

#128

Post by giancarlostoro »

williamdclt wrote: post #49
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.

Well so far we've been using humans to clean up the code that humans ruined in the first place, it's hardly a logical fallacy

The pearl clutching about AI is insane to me, as if code quality was perfect before 2022. We have been seeing a decline in software quality for a long time coming now. A lot of AI hatred is not even based on seeing something genuinely bad, its just prejudice for the sake of prejudice. If I could view into two parallel worlds, one where I vibe code something, release it and tell people it's vibe coded, and another where I do the same but tell no one, codebases are both the same and I still reviewed the code, had the model fix issues with code quality and bugs, and genuinely invested hours of my time to raise up, in the universe where I don't mention AI, people will likely sing praises, in the universe where I do mention AI, people will not even review or view a single line of code, they will close the tab, hop back on HN and complain that it's AI slop, without any reasonable reason.

Blind AI hatred is just insane to me and it goes against the spirit of HN, we're not supposed to just go "ITS BAD CODE" here, we are supposed to have actual engaging conversations. Too much of HN devolves into "ITS SLOP" instead of "Hey, I know you're leaning on the AI a bit, but here's what's wrong with the code: ...." which would be more constructive and fall better in line with what I've expected from HN and seen for years, until recently.

AI fatigue and AI prejudice should not be confused for one another, sure you can have both, but most people who hate AI blindly just have AI prejudice at this point.

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

#129

Post by christophilus »

robertlagrant wrote: post #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'…

It's less than I'd expect, given how Bun was developed. I'm sure there's plenty more of that to be had in that codebase.

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

#130

Post by christophilus »

1a527dd5 wrote: post #47

This is what I like to call performative performance programming. I _LOVE_ performance as much as the next guy. And build times should be as close to 0 seconds as possible. But this is approaching diminishing returns and I guarantee that your CURRENT bottleneck is not build times.

No. Fast builds are a must for a project like this, in my opinion. This is an important step towards making the project easier to maintain.
Post reply on HN