Comment by anp
5 years ago
I was thinking of The Lisp Curse[1] while reading your comment and then you mentioned the language! I’m quite excited by Zig (even if safety is lower priority for it than for Rust, it is really pushing the tooling envelope) but I do wonder whether the “anti-composition hypothesis” here holds up for relevant projects today. Many C programs include shims for compatibility between multiple different “library object models” (hell even strings count here) and they seem to be a common source of security and performance issues. Maybe in the domains where Zig is most competitive that dynamic won’t play out? Or maybe comptime provides tools that will still enable composition or at least allow for lower overhead “object model shims”? I suspect that it will be hard to know more about how it plays out until there is more language stability and code sharing, maybe even a repository like npm or crates.io.
[1] http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
Can the "safety is lower priority than rust" trend stop? Zig is not less concerned with safety and will catch illegal behaviour at runtime for that which isn't caught at compile-time. It's only ReleaseSmall and ReleaseFast that elide this where you're able to toggle safety checks via a builtin if you wish. There's ongoing work to provide more of it within the standard library with the GeneralPurposeAllocator being an example of it.
I'm not suggesting that Zig isn't concerned with safety, but it's not a language designed first and foremost to offer certain safety properties. For Rust you can say "as long as you don't write the `unsafe` keyword in Rust, you'll never introduce memory or thread unsafety". Is there an equivalent for Zig? Not AFAIK but I'd actually be quite happy to be shown wrong.
Use after free is the big one Zig still doesn't protect against. Yet?
So I think it's a fair statement. Rust is safety obsessed. Zig is doing its best while paying top tribute to other gods.
I would put it differently. Rust sacrifices anything -- including things that may hurt other aspects of correctness -- to soundly guarantee (assuming the compiler is correct) no undefined behaviour in its safe subset (and yet makes some concessions, as a large percentage of Rust programs do employ unsafe code, and so don't make such a strong guarantee), while Zig finds a different balance, at times sacrificing possible UB for the sake of helping with functional correctness. Even if you look at correctness only, it is unclear which approach, if any, offers a better story.