[bunderbunder]

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

[dnautics]

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

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.

[skeledrew]

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

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

[TheGoddessInari]

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 dependent on in context learning & instruction following.

[skeledrew]

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

[maleldil]

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

[bunderbunder]

Yup. But that also gets to the “they’re both right” angle. Zig’s convention may not be how the Bun developers wanted to work, but it’s a good choice for the kinds of projects Zig is designed for. Which overlaps a bit with, but isn't the same as, Rust’s intended use cases. For example, I might rather go with the Zig philosophy if I’ve got hard memory constraints and want to avoid dynamic memory allocation.

Which, ironically, is something I’d love for my browser’s JavaScript runtime to do. But I can also respect others not wanting that.