5 ms·

Has anyone tried Zig? From reading the project page I don't see anything that it has/plans over something like Rust that's much further along.

AnIdiotOnTheNet 8y ago
I write a lot of Zig. In fact, all my hobby projects are in Zig since I've started using it because I like it so much. I haven't tried Rust, but I've seen enough of it to know I'd hate it. Where Zig has a clear advantage is that it is vastly smaller and simpler and does not enforce a memory management paradigm on you. There isn't even a default allocator.
striking 8y ago
Rust seems like a spiritual successor to C++. Zig seems like a spiritual successor to C (except it's a little closer to C, as you can directly run things from C in Zig)
- nicoburns 8y ago
  Came here to say the same thing. I think there is probably room for both. Seems like the are valid use cases where you might want something with completely manual management like C, but without footguns like undefined behaviour and c-style strings.
gmfawcett 8y ago
Error management is different, and quite uniquely done. Zig deals with failure modes in a much more fine-grained way than Rust, which favours the algebraic-wrapper approach (Result / Option types). If you're writing actual, low-level systems code, your code might need to react differently depending on the failure mode: you need to know if it was an I/O issue, or out-of-memory, or disk-full, or etc. At the call point, Zig lets you enumerate all of the possible failure reasons comprehensively, and handle each one specifically if you choose to. This enumeration is produced and checked by the compiler, so you can't miss any cases. (It also lets you disregard the specifics if you don't care.)
- dbaupp 8y ago
  That sounds quite similar to Rust, except less fine-grained than Rust. The Result type has an Error parameter which is usually an enumeration of the possible failure conditions, e.g. https://doc.rust-lang.org/std/io/struct.Error.html https://doc.rust-lang.org/std/io/struct.Error.html . That is, an IO function returns only IO errors, as compared to Zig's strategy which unifies all declared errors in the program into a single "error" enumeration. (To be clear, there's a lot of cases when this precision isn't so useful, but the contention here is how fine grained they can be.)
  - gmfawcett 8y ago
    There's definitely there's a distinction here between the approach you've described (Rust can indicate that a function returns only IO errors -- but doesn't tell you which subset of "all IO errors" might actually occur at this call point) and Zig's (the function call can result in an arbitrary set of specific errors, some of which might be IO and some might not; and only the actually possible errors are included in the set). Is one better than the other? I doubt that question has an objective, one-size-fits-all answer. I'm happy to see experimentation in this domain! My point really is just that Zig is different from Rust in how it handles errors, even if there are some superficial similarities.
    - dbaupp 8y ago
      I think you haven't understood my point or maybe I haven't understood yours, and maybe it is because I have misunderstood Zig's approach. My understanding is that something like `fn f() -> %T` returns a T or an `error`, and the latter can be literally any error value that exists anywhere in the program. It isn't restricted to the actual possible errors that might occur inside f, and thus has the same failings of Rust that you point out (don't know which subset of errors might be returned), except the unknown set of possible errors is likely to be larger. (And, you can still get all the niceties of Rust's error handling infrastructure like the ? operator if you manually define an error type that is restricted to the exact set of possible errors: there's not a privileged type for how to represent errors.)

AnIdiotOnTheNet 8y ago

I write a lot of Zig. In fact, all my hobby projects are in Zig since I've started using it because I like it so much. I haven't tried Rust, but I've seen enough of it to know I'd hate it. Where Zig has a clear advantage is that it is vastly smaller and simpler and does not enforce a memory management paradigm on you. There isn't even a default allocator.

striking 8y ago

Rust seems like a spiritual successor to C++. Zig seems like a spiritual successor to C (except it's a little closer to C, as you can directly run things from C in Zig)

nicoburns 8y ago
Came here to say the same thing. I think there is probably room for both. Seems like the are valid use cases where you might want something with completely manual management like C, but without footguns like undefined behaviour and c-style strings.

gmfawcett 8y ago

Error management is different, and quite uniquely done. Zig deals with failure modes in a much more fine-grained way than Rust, which favours the algebraic-wrapper approach (Result / Option types). If you're writing actual, low-level systems code, your code might need to react differently depending on the failure mode: you need to know if it was an I/O issue, or out-of-memory, or disk-full, or etc. At the call point, Zig lets you enumerate all of the possible failure reasons comprehensively, and handle each one specifically if you choose to. This enumeration is produced and checked by the compiler, so you can't miss any cases. (It also lets you disregard the specifics if you don't care.)

dbaupp 8y ago
That sounds quite similar to Rust, except less fine-grained than Rust. The Result type has an Error parameter which is usually an enumeration of the possible failure conditions, e.g. https://doc.rust-lang.org/std/io/struct.Error.html https://doc.rust-lang.org/std/io/struct.Error.html . That is, an IO function returns only IO errors, as compared to Zig's strategy which unifies all declared errors in the program into a single "error" enumeration. (To be clear, there's a lot of cases when this precision isn't so useful, but the contention here is how fine grained they can be.)
- gmfawcett 8y ago
  There's definitely there's a distinction here between the approach you've described (Rust can indicate that a function returns only IO errors -- but doesn't tell you which subset of "all IO errors" might actually occur at this call point) and Zig's (the function call can result in an arbitrary set of specific errors, some of which might be IO and some might not; and only the actually possible errors are included in the set). Is one better than the other? I doubt that question has an objective, one-size-fits-all answer. I'm happy to see experimentation in this domain! My point really is just that Zig is different from Rust in how it handles errors, even if there are some superficial similarities.
  - dbaupp 8y ago
    I think you haven't understood my point or maybe I haven't understood yours, and maybe it is because I have misunderstood Zig's approach. My understanding is that something like `fn f() -> %T` returns a T or an `error`, and the latter can be literally any error value that exists anywhere in the program. It isn't restricted to the actual possible errors that might occur inside f, and thus has the same failings of Rust that you point out (don't know which subset of errors might be returned), except the unknown set of possible errors is likely to be larger. (And, you can still get all the niceties of Rust's error handling infrastructure like the ? operator if you manually define an error type that is restricted to the exact set of possible errors: there's not a privileged type for how to represent errors.)