alt Hacker NewsDrilling into the original article where Jarred explained the reasoning behind the change, It's pretty clear that under zig the team was doing things by hand that are automatic in rust.
Humans and agents share one thing: they are both non-deterministic. He talks about the issue of tracking memory lifecycles manually in zig so it can be explicitly freed. As expected, this leads to a long list of bugs where people missed things.
Rust does this automatically. It removes an entire class of errors from his backlog. From an engineering management perspective, this looks like a pretty good trade.
The bonus here is that compiler errors are exactly the kind of deterministic guardrail you need to put around coding agents. Claude works really well if you give it a way to test for correctness and "make it compile" is a pretty good target.
There's a general version of this: the artifact you expose plus the test you run on it. Deterministic tests turn stochastic output into a hard guarantee. Wrote it up here if useful: https://michael.roth.rocks/blog/verification-surface/
Replies
I thought that this was just an initial translation to unsafe rust in which they haven't actually gained any of those benefits yet, although presumably they can go there quickly now.
> Rust does this automatically.
A garbage collected language does this automatically. Rust still requires thinking about and tracking memory lifecycles, but the borrow checker will complain and keep you from doing it wrong. That's why LLMs like Rust. It gives immediate feedback on what to fix. By-default constant reference parameters helps prevent major performance problems.
> Rust does this automatically. It removes an entire class of errors from his backlog.
Even with the huge amount of "unsafe" rust currently in bun? https://news.ycombinator.com/item?id=48967630
i found the same thing with Rust, verification steps are really helpful for speed and correctnesss
Good thing there are tons of languages that do that out of the box, and which are frankly quite fast.
I seem to recall this Rust rewrite is all "unsafe" meaning it really doesn't automatically eliminate those issues.
> He talks about the issue of tracking memory lifecycles manually in zig so it can be explicitly freed. As expected, this leads to a long list of bugs where people missed things.
Yes, and again the "you're holding it wrong" people or "you are not a good enough developer" people will try to do juggling with a chainsaw and lose a couple of fingers in the process
Claude Code's endorsement (and real-world testing) speaks louder than internet discussions that are at this point 30 years old (and probably more)
LLMs catch memory bugs quite easily in my experience.
All of this is just a (succesful) marketing stunt by Anthropic.
> "make it compile" is a pretty good target.
But only as far as "make it compile" is a good predictor of runtime behavior. In C++ for instance, I can "make it compile" and it still crashes at runtime or does other undesirable things.
Rust is the clear winner of LLM era, you can't say otherwise.
[dead]
Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things".
You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (like what llms generally prefer), it doesn't make sense to use it.