I maybe am reading too much into this, but it's weird to me that a zig lead would be posting about an AI-only project despite zig's stance on AI. Maybe zig's official stance isn't that well supported in their own community.
Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
191–200 of 202 posts
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#192Earlier quoted context omitted.
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 mor…
> my personal style deviates from the common practices.
The closest I could get to mine was by telling it to write like a Unix hacker. Hahaha
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#193Earlier 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…
"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…
> 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.
I'm inclined to agree. If I had to write a hypothesis, I would say that is' likely that people like me underestimate the capability of the tools, and people who disagree likely underestimate the amount of manual steering and/or overlook the things that I find offensive!
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#194Earlier quoted context omitted.
> using the language the way it wants to be used. This sounds like just the coding conventions dependency they're trying to avoid.
IMO it's the same problem with Rust. LLMs are trained on vast quantities of code that violate Rust soundness in safe code. LLMs are prediction engines: you can move the needle (heavily) on the predictions from lazy to correct by construction, but the defaults even on high end models like Opus are always riddled with shortcuts. LLMs can produce coherent & safe Rust 1.92, LLMs can produce coherent Zig 0.16, but that's…
> LLMs are trained on vast quantities of code that violate Rust soundness in safe code.
Why is your reasoning behind this? Most Rust code in the wild does not use unsafe. Most projects don't have a single line of unsafe.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#195Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#196what is this obsession with bun and js in general? with all this vibe coding why not fix the reasons we needed js in the first place
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#197Earlier quoted context omitted.
> using the language the way it wants to be used. This sounds like just the coding conventions dependency they're trying to avoid.
IMO it's the same problem with Rust. LLMs are trained on vast quantities of code that violate Rust soundness in safe code. LLMs are prediction engines: you can move the needle (heavily) on the predictions from lazy to correct by construction, but the defaults even on high end models like Opus are always riddled with shortcuts. LLMs can produce coherent & safe Rust 1.92, LLMs can produce coherent Zig 0.16, but that's…
> that's dependent on in context learning & instruction following
Not just that. For Rust in particular, since unsafe code is uncompilable code (unless explicitly marked "unsafe"), the LLM is essentially forced to continue iterating even if the code already works but is unsafe, until it finds an implementation that's both correct (per the spec) and safe (per the compiler). That's the difference from Zig, where "make the code safe" is essentially part of the spec, and so may be missed by the LLM and not be discovered by a human until there's an observable runtime issue, or CVE.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#198Earlier 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…
I'm optimistic for that refactoring. But if one in 30 lines sprinkled all over everywhere is unsafe then you haven't actually done much to improve safety. When you have a large percent of fully safe functions and modules, that's when you're making a difference. Counting the lines is not a very helpful metric.
> one in 30 lines
> Counting the lines is not a very helpful metric.
Seems self-contradictory.
And they did say they're working to reduce the unsafe code over time. That huge percentage of memory bugs that they were able to better triage and fix due to the port was also them improving safety.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#199Earlier quoted context omitted.
I'm optimistic for that refactoring. But if one in 30 lines sprinkled all over everywhere is unsafe then you haven't actually done much to improve safety. When you have a large percent of fully safe functions and modules, that's when you're making a difference. Counting the lines is not a very helpful metric.
> one in 30 lines > Counting the lines is not a very helpful metric. Seems self-contradictory. And they did say they're working to reduce the unsafe code over time. That huge percentage of memory bugs that they were able to better triage and fix due to the port was also them improving safety.
The other part of that line is important. Measuring lines is better than nothing but the distribution is much more important. If they're scattered all over that's a bigger downside than the line reduction is an upside.
If you want good metrics, measure functions and data structures without unsafe. Not lines.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#200Earlier quoted context omitted.
> one in 30 lines > Counting the lines is not a very helpful metric. Seems self-contradictory. And they did say they're working to reduce the unsafe code over time. That huge percentage of memory bugs that they were able to better triage and fix due to the port was also them improving safety.
The other part of that line is important. Measuring lines is better than nothing but the distribution is much more important. If they're scattered all over that's a bigger downside than the line reduction is an upside. If you want good metrics, measure functions and data structures without unsafe. Not lines.
> If you want good metrics, measure functions and data structures without unsafe.
I doubt it, as it's possible a substantial amount of those unsafe areas can't even be removed, given the project's dependent on C/C++ libraries. Without proper calibration those metrics won't tell the full story, and with calibration the incentive for the story will decrease over time with the unsafe refactoring. I doubt the distribution of the unsafe code really matters that much; what matters is proper handling, wherever it is, so stability and security isn't compromised.