4 ms·

My understanding is that Zig has all of the power and modernity of Rust, without the strictness and borrow checker. Unlike Rust, it also has powerful compile-ti

My understanding is that Zig has all of the power and modernity of Rust, without the strictness and borrow checker. Unlike Rust, it also has powerful compile-time evaluation and custom allocators, and probably more improvements I'm not familiar with (in Rust you can effectively emulate custom allocators, but you have to rewrite every allocating structure to use them; or you can use nightly, but most third-party library and even some standard-library types don't support them). I also heard someone say "Zig is to C what Rust is to C++". Which I interpret as, it's another maximum-performance modern language, but smaller than Rust; "smaller" meaning that it has less safety and also abstraction (no encapsulation [1]), but less requirements and complexity. Particularly with games, many devs want to build a working prototype really fast and then iterate fast. They don't want to deal with the borrow checker especially if their code has a lot of complex lifetime rules (and the borrow checker is a real issue; it caused evanw to switch esbuild to Go [1]). In small scripts with niche uses, safety and architecture are a waste of effort, the script just has to be done and work (and the latter is only partly necessary, because the script may not even be fed enough inputs to cover edge cases). Plus, there are plenty of projects where custom allocation is especially important, and having every type support custom allocation is a big help vs. having to rewrite every type yourself or use `no_std` variants. [1] https://github.com/ziglang/zig/issues/2974 https://github.com/ziglang/zig/issues/2974 [2] https://github.com/evanw/esbuild/issues/189#issuecomment-647024185 https://github.com/evanw/esbuild/issues/189#issuecomment-647...

lenkite 3y ago
Also none of the common knowledge around traditional data-structures and algorithms work with Rust anyways. One needs to dance like a ballerina with their hands and feet tied.
- pkulak 3y ago
  “Linked lists are hard” is not “none of the common knowledge around traditional data-structures and algorithms work”.
  - DeathArrow 3y ago
    Ever tried to implement generic trees in Rust?
    - herbstein 3y ago
      Trees are easy. It's the desire to have backreferences - making it a graph - that kills you.
  - bsder 3y ago
    I retort that almost all of the concurrent data structures are obnoxious to represent in Rust. A lock-free ConcurrentHashMap, for example, is by no means a straightforward data structure in a non-GC language. Even if you somehow dodge Rust's pedantry, you still have to figure out who owns what, who pays for what and when they pay for it--and there are multiple valid choices! Non-GC allocation/deallocation in concurrent data structures probably still qualifies as a solid CS problem. (And, before you point me to your favorite crate for ConcurrentHashMap, please check it's guarantees when one process needs to iterate across keys while another process simultaneously is inserting/deleting elements. You will be shocked at how many of them need to pull a lock--so much for lock-free.)
    - richardwhiuk 3y ago
      You should always know who owns some data, even if you aren't using Rust!
      - rafram 3y ago
        Garbage collection means the VM owns it! And that’s great. How it should be.
        richardwhiuk 3y ago
        Welcome to a land of memory bloat because you've got a chain to a reference due to a lack of clear ownership.
Arnavion 3y ago
>My understanding is that Zig has all of the power and modernity of Rust, without the strictness and borrow checker. This is an oxymoron :) The strictness and borrow checker are part of the power and modernity of Rust. But even apart from that, Rust has automatic value-based destructors (destructor follows the value as it's moved across scopes and is only called in the final scope), whereas Zig only has scope-based destructors (defer) and you need to remember to write them and ensure they're called exactly once per value. Rust has properly composable Option/Result monads, whereas Zig has special-cased ! and ? which don't compose (no Option of Option or Result of Result) but do benefit from nice built-in syntax due to their special-cased-ness. Rust has typed errors whereas Zig only has integers, though again that allows Zig to have much simpler syntax for defining arbitary error sets which would require defining a combinatorial explosion of enums in Rust. Of course from Zig's point-of-view these are features, not deficiences, which is completely understandable given what kind of language it wants to be. And the other advantages you listed like comptime (Rust's const-eval is very constrained and has been WIP for ages) and custom allocator support from day 1 (the way Rust is bolting it on will make most existing code unusable with custom allocators, including parts of Rust's own standard library) are indeed good advantages. Zig also has very nice syntax unification - generic types are type constructor functions fn(type) -> type, modules are structs, etc. I hope that one day we'll have a language that combines the best of Rust's strictness and Zig's comptime and syntax.
- Ygg2 3y ago
  > Rust's const-eval is very constrained and has been WIP for ages Having strong backwards compatibility does that to the language, alternative is arguably worse (see Python 2 vs 3).
  - Arnavion 3y ago
    Yes, and I don't want a backward-incompatible Rust 2.0 either, but the slowness of stabilizing ! (named for when it's going to be stabilized), specialization, TAIT, const-eval, Vec::drain_filter, *Map::raw_entry, ... is annoying. Also the lack of TAIT currently causes actual inefficiency when it comes to async traits, because currently async trait methods have to return allocated virtualized futures instead of concrete types. Same for Map::raw_entry, without which you have to either do two lookups (`.get()` + `.entry()`) or always create an owned key even if the entry already exists (`.entry(key.to_owned())`).
binary132 3y ago
I think Rust and Zig are very different in principals and shouldn’t really be compared. It’s almost like comparing C and Ada.

lenkite 3y ago

Also none of the common knowledge around traditional data-structures and algorithms work with Rust anyways. One needs to dance like a ballerina with their hands and feet tied.

pkulak 3y ago
“Linked lists are hard” is not “none of the common knowledge around traditional data-structures and algorithms work”.
- DeathArrow 3y ago
  Ever tried to implement generic trees in Rust?
  - herbstein 3y ago
    Trees are easy. It's the desire to have backreferences - making it a graph - that kills you.
- bsder 3y ago
  I retort that almost all of the concurrent data structures are obnoxious to represent in Rust. A lock-free ConcurrentHashMap, for example, is by no means a straightforward data structure in a non-GC language. Even if you somehow dodge Rust's pedantry, you still have to figure out who owns what, who pays for what and when they pay for it--and there are multiple valid choices! Non-GC allocation/deallocation in concurrent data structures probably still qualifies as a solid CS problem. (And, before you point me to your favorite crate for ConcurrentHashMap, please check it's guarantees when one process needs to iterate across keys while another process simultaneously is inserting/deleting elements. You will be shocked at how many of them need to pull a lock--so much for lock-free.)
  - richardwhiuk 3y ago
    You should always know who owns some data, even if you aren't using Rust!
    - rafram 3y ago
      Garbage collection means the VM owns it! And that’s great. How it should be.
      - richardwhiuk 3y ago
        Welcome to a land of memory bloat because you've got a chain to a reference due to a lack of clear ownership.

Arnavion 3y ago

>My understanding is that Zig has all of the power and modernity of Rust, without the strictness and borrow checker. This is an oxymoron :) The strictness and borrow checker are part of the power and modernity of Rust. But even apart from that, Rust has automatic value-based destructors (destructor follows the value as it's moved across scopes and is only called in the final scope), whereas Zig only has scope-based destructors (defer) and you need to remember to write them and ensure they're called exactly once per value. Rust has properly composable Option/Result monads, whereas Zig has special-cased ! and ? which don't compose (no Option of Option or Result of Result) but do benefit from nice built-in syntax due to their special-cased-ness. Rust has typed errors whereas Zig only has integers, though again that allows Zig to have much simpler syntax for defining arbitary error sets which would require defining a combinatorial explosion of enums in Rust. Of course from Zig's point-of-view these are features, not deficiences, which is completely understandable given what kind of language it wants to be. And the other advantages you listed like comptime (Rust's const-eval is very constrained and has been WIP for ages) and custom allocator support from day 1 (the way Rust is bolting it on will make most existing code unusable with custom allocators, including parts of Rust's own standard library) are indeed good advantages. Zig also has very nice syntax unification - generic types are type constructor functions fn(type) -> type, modules are structs, etc. I hope that one day we'll have a language that combines the best of Rust's strictness and Zig's comptime and syntax.

Ygg2 3y ago
> Rust's const-eval is very constrained and has been WIP for ages Having strong backwards compatibility does that to the language, alternative is arguably worse (see Python 2 vs 3).
- Arnavion 3y ago
  Yes, and I don't want a backward-incompatible Rust 2.0 either, but the slowness of stabilizing ! (named for when it's going to be stabilized), specialization, TAIT, const-eval, Vec::drain_filter, *Map::raw_entry, ... is annoying. Also the lack of TAIT currently causes actual inefficiency when it comes to async traits, because currently async trait methods have to return allocated virtualized futures instead of concrete types. Same for Map::raw_entry, without which you have to either do two lookups (`.get()` + `.entry()`) or always create an owned key even if the entry already exists (`.entry(key.to_owned())`).

binary132 3y ago

I think Rust and Zig are very different in principals and shouldn’t really be compared. It’s almost like comparing C and Ada.