←back to thread

Interview with Zig language creator Andrew Kelley [video]

(www.youtube.com)
200 points jorangreef | 9 comments | 27 Aug 20 11:10 UTC | HN request time: 0s | source | bottom
Show context
tobz1000 ◴[27 Aug 20 13:08 UTC] 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 ◴[27 Aug 20 13:13 UTC] 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. edflsafoiewq ◴[27 Aug 20 20:40 UTC] No.24298380[source]▶
Does zig have an answer to RAII yet?
replies(1): >>24300178 #
2. pron ◴[28 Aug 20 00:20 UTC] No.24300178[source]▶
RAII is not a question. Zig prefers explicitness, i.e. by looking at a subroutine you know exactly which code is called, its approach to releasing resource uses defer.
replies(1): >>24300366 #
3. edflsafoiewq ◴[28 Aug 20 00:57 UTC] No.24300366[source]▶
The question is how to do automatic resource management. There are no checks of any sort, runtime or not, to help you here (correct me if I'm wrong).

RAII is not precluded by explicitness, you could require all values that require cleanup to be syntactically marked in some way and it would still be RAII. defer also cannot handle resources whose lifetimes do not correspond to nested scopes (eg. the elements of an ArrayList) like RAII or a GC can.

replies(2): >>24306357 #>>24359288 #
4. pron ◴[28 Aug 20 15:53 UTC] No.24306357{3}[source]▶
> RAII is not precluded by explicitness, you could require all values that require cleanup to be syntactically marked in some way and it would still be RAII.

I think this one is TBD.

> defer also cannot handle resources whose lifetimes do not correspond to nested scopes (eg. the elements of an ArrayList) like RAII or a GC can.

Yep, defer won't work if there is no known lifetime scope, but I think this one is actually a good tradeoff to make in a low-level language. Don't get me wrong -- I love tracing GCs and think that they're the right choice for the vast majority of application software, plus there have been great strides made in GC capabilities in the past few years, but in the domains where low-level languages are appropriate there is a different set of constraints. Low-level programming is not like high-level programming, and IMO it's wrong to even try to make them look alike.

5. int_19h ◴[02 Sep 20 23:14 UTC] No.24359288{3}[source]▶
> defer also cannot handle resources whose lifetimes do not correspond to nested scopes

It can, it's just more explicit about it. In a language with destructors, you'd do RAII here by having a list destructor that cleans up each element in turn. In a language with defer, the same destructor becomes a regular function that you'd invoke in the deferred expression.

replies(2): >>24379048 #>>24379109 #
6. ◴[04 Sep 20 21:25 UTC] No.24379048{4}[source]▶
7. edflsafoiewq ◴[04 Sep 20 21:33 UTC] No.24379109{4}[source]▶
The issue is with the individual elements, which get pushed to the list, popped off the list, moved around, pushed to a different list, etc.

The other issue is since there is no generic notion of a destructor, it isn't possible to write generic functions that destroy elements. If you call, say, replace_range on a list of strings, it will leak the replaced strings.

replies(1): >>24404277 #
8. int_19h ◴[08 Sep 20 01:06 UTC] No.24404277{5}[source]▶
> The issue is with the individual elements, which get pushed to the list, popped off the list, moved around, pushed to a different list, etc.

That's separate from the destructor for the entire list. It does mean that the code that removes an element from the list has to explicitly invoke the destructor for it - which is in agreement with using "defer" to explicitly invoking destructors for locals.

> The other issue is since there is no generic notion of a destructor, it isn't possible to write generic functions that destroy elements.

But you can have a generic notion of a destructor - that's orthogonal to whether destructors are invoked explicitly. You just have an interface (or trait, or whatever it's called) that exposes a destructor method for a type.

replies(1): >>24438025 #
9. edflsafoiewq ◴[11 Sep 20 00:27 UTC] No.24438025{6}[source]▶
You could but Zig does not.