To be fair, there are caveats still in place today: Zig incremental compilation does not yet support aarch64 and only the linux linker supports binary patching, but it's just a matter of time before all major platforms are conquered.
Turns out there's a journey here.
"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,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomatic Rust, but we are going to continue using C & C++ libraries like JavaScriptCore so it will always have more unsafe than pure Rust projects."
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.
This sounds like just the coding conventions dependency they're trying to avoid.
Which, ironically, is something I’d love for my browser’s JavaScript runtime to do. But I can also respect others not wanting that.
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 dependent on in context learning & instruction following.
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.
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.
agreed. in my side project im tinkering with a memory safety checker in zig that intercepts a compiler artifact, and it works better with idiomatic zig, problematic code is when you try to write c-isms in zig -- so i basicallt tell the checker to reject c-isms that create ambiguity for safety checking.
> 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.
If you want good metrics, measure functions and data structures without unsafe. Not lines.
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.
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.
Do you know what's infinitely cheaper and faster than an LLM running nightly reviews of all of the code and infact mathematically provable that the code (and any new code) is memory safe? It's called the borrow checker.
(my wip experiment: ) https://github.com/ityonemo/clr
Surely it's obvious that's trivially untrue?
Also, literally no code is safe from potential future upstream changes.
Anyway, I'm not arguing zig has the same safety guarantees as rust. That would be silly. But the weird binary thinking around memory safety is equally silly. People want things to be simple, but you really can't come to good conclusions by trying to pretend things are simpler than they are and through a lack of analysis and thinking.
Anthropic submitted to patch the Zig compiler to improve Bun compilation times, it was rejected. One reason it was rejected is that it contained AI-generated code, which is against the community guidelines, but more importantly, it would have been rejected regardless of AI use. They claimed a 4x improvement, something like going from 2 minutes to 30 seconds, but, according to the Zig team, it made compilation non-deterministic, and missed on the real improvement they worked on, which was sub-1s incremental builds.
"Buz" shows that the fork submitted by Anthropic wasn't needed as Bun can now compile under 1s (incrementally), which is much better than the 30s they achieved with their patch.
It is likely that this rejection, especially the "no AI" aspect of it encouraged Anthropic to move away from Zig.
Probably because they did their fork of zig for fast compilation before and they didn’t want to just discard it and use this