←back to thread

200 points jorangreef | 2 comments | | HN request time: 0.425s | source
Show context
tobz1000 ◴[] No.24293284[source]
Some of Zig's ideas fascinate me, both the great low-level concepts (e.g. arbitrary-sized ints), but much more than that, the high level concepts.

Particularly great is Zig's handling of both macros and generic types, the answer to both of which seems to be: just evaluate them at compile-time with regular functions, no special DSL or extra syntax. Andrew mentions in the video a big drawback of this system - implications for IDE complexity and performance. I imagine the performance side of this could be (maybe is?) mitigated by limiting recursion depth/loop counts for compile-time work.

I'm not particularly interested in taking on a language with manual memory management and the responsibilities it entails, but I would love to have access to Zig's compile-time capabilities, if it were available with some more memory safety.

replies(2): >>24293329 #>>24294235 #
pron ◴[] No.24293329[source]
Zig gives you memory safety (or, rather, will ultimately do that), but it does so in a way that's different from both languages with garbage collection (whether tracing or reference-counting) or with sound type-system guarantees a-la Rust. It does so with runtime checks that are turned on in development and testing and turned off -- either globally or per code unit -- in production. You lose soundness, but we don't have sound guarantees for functional correctness, anyway, and given that Zig makes testing very easy, it's unclear whether a particular approach dominates the other in terms of correctness.
replies(6): >>24293512 #>>24293563 #>>24293661 #>>24296835 #>>24298380 #>>24299940 #
1. vmchale ◴[] No.24296835[source]
That's not on par with linear or affine types.
replies(1): >>24299103 #
2. pron ◴[] No.24299103[source]
When compared in isolation, yes. But such mechanisms aren't free; they add to both language complexity and compilation time, two things that can have a negative impact on correctness. So it's impossible to say which approach leads to more correct programs overall without empirical study.

We see similar tradeoffs of soundness in formal verification as well. We're not talking about exactly the same thing here (because affine type safety is compositional) but the general principle is the same: soundness has a cost, and it is not necessarily the most efficient way of achieving a required level of correctness.

Anyway, I think that both Rust and Zig have very interesting approaches to safety, but I don't think we know enough to claim one is more effective than the other at this time.