5 ms·

This is absolutely not what the article is about. A good majority of it is spent on the myth that Zig is safer than Rust, which has nothing to do with wishing Z

This is absolutely not what the article is about. A good majority of it is spent on the myth that Zig is safer than Rust, which has nothing to do with wishing Zig was more like Rust.

chrisco255 2y ago
Is there a myth that makes that claim? Virtually every take I've heard is that Zig is "safe enough" while giving developers more control over memory and actually, it's specifically better for cases where you must write unsafe code, as it's not possible to express all programs in safe Rust.
- bobbylarrybobby 2y ago
  If you must write unsafe code, what's wrong with just dropping down to unsafe in Rust when you need to? You have all the power unsafe provides, and you have a smaller surface area to audit than if your entire codebase resides in one big unsafe block.
  - chrisco255 2y ago
    Unsafe Rust is problematic: https://zackoverflow.dev/writing/unsafe-rust-vs-zig https://zackoverflow.dev/writing/unsafe-rust-vs-zig See also: https://github.com/roc-lang/roc/blob/main/www/content/faq.md#why-does-roc-use-both-rust-and-zig-rust-and-zig https://github.com/roc-lang/roc/blob/main/www/content/faq.md... Zig is not entirely unsafe. It provides quite a few compile time checks and primitives to catch memory leaks or prevent them altogether.
    - oneshtein 2y ago
      Yes, unsafe code is problematic in Rust, C, C++, etc. Is Zig different?
      - mk12 2y ago
        It’s harder to write correct unsafe Rust than correct Zig because (1) Rust uses references all over the place, but when writing unsafe code you must scrupulously avoid “producing” an invalid reference (even if you never deference it), and (2) there’s lots of syntax noise which obscures what the code is doing (though &raw is a step in the right direction).
        zozbot234 2y ago
        > Rust uses references all over the place This is mostly a concern with the Rust stdlib, though. And it's in principle fixable, by writing new varieties of those stdlib functions that take raw-pointer or &UnsafeCell<...> arguments, and delegating the "safe" varieties to those.
        kprotty 2y ago
        There's compiler-level traits like `Iterator` and `Future` which enforce references. If wanting to do intrusive pointers into them, one risks creating overlapping references: https://github.com/tokio-rs/tokio/issues/3399 https://github.com/tokio-rs/tokio/issues/3399
        zozbot234 2y ago
        References to UnsafeCell<> should still be safe, because the only thing you can do with an &UnsafeCell<T> is extract a possibly-mutating raw pointer to T. (UnsafeCell<> is also special in that, like Cell<>, you can mutate through it without incurring UB.)
        oneshtein 2y ago
        For Rust references, rules[0] are not hard to follow: The pointer must be properly aligned. It must be non-null. It must be “dereferenceable”: a pointer is dereferenceable if the memory range of the given size starting at the pointer is entirely contained within the bounds of that allocated object. Note that in Rust, every (stack-allocated) variable is considered a separate allocated object. The pointer must point to a valid value of type T. When creating a mutable reference, then while this reference exists, the memory it points to must not get accessed (read or written) through any other pointer or reference not derived from this reference. When creating a shared reference, then while this reference exists, the memory it points to must not get mutated (except inside UnsafeCell). [0]: https://doc.rust-lang.org/stable/core/ptr/index.html#pointer-to-reference-conversion https://doc.rust-lang.org/stable/core/ptr/index.html#pointer...
    - zamalek 2y ago
      This is precisely the myth that the article talks about. Miri finds significantly more UB in unsafe Rust than Zig's checks do. Even if it weren't, this exaggeration is a complete theater. You aren't supposed to use unsafe Rust unless you really have to. I have been using Rust since 2020 and I've used it once, for 3 lines of code. The entirety of all Zig codebases is unsafe. That's fine if you are fine with unsafe code, but this myth is dishonest, and I take great issue with using a language where the founder is the primary source of the dishonesty - because what else is being swept under the rug?
      - throwawaymaths 2y ago
        yes but by the time you're using miri, why not just run zig with a separate static checker that does all the memory safety parts? https://github.com/ityonemo/clr https://github.com/ityonemo/clr
        pcwalton 2y ago
        For one, it doesn't do all the "memory safety parts", according to the readme. I'm very skeptical that Zig can be made memory safe with a checker while still remaining compatible with existing code. Certainly neither C nor C++ can, and Zig isn't meaningfully different in expressivity (if anything, it's more expressive, which is the opposite of what you want).
        throwawaymaths 2y ago
        FTrepo: Q: You didn't do X, so Zig will never be able to track X A: Maybe. Only way to know for sure is to fork this (or, hopefully, a 'real' successor) and fail. However, consider that "trivially" it should be possible to externally annotate every zig file with lifetime/type annotations identical to that of Rust and run "exactly the same" analysis as Rust and get the same memory safety as Rust. it appears the clr author anticipated you: you didnt fork it, try, and fail, so you have ceded the authority to credibly make your speculative complaint > Zig isn't meaningfully different in expressivity it is meaningfully different in expressivity at the AIR level. AIR looks nothing like c, c++, zig, or rust.
    - pcwalton 2y ago
      > It provides quite a few compile time checks and primitives to catch memory leaks or prevent them altogether. From what I've seen, clang has all of these and more for C++. If your metric is "tooling to help you catch UB", C++ is significantly superior to Zig.
      - chrisco255 2y ago
        Zig has a C and C++ compiler built into it and works seamlessly with it. Several C/C++ projects use Zig as a build tool. Zig makes different trade-offs with C++ from a language design standpoint. C++ has a lot more footguns to create UB in the first place.
        pcwalton 2y ago
        > C++ has a lot more footguns to create UB in the first place. I'd actually give the edge to C++ over Zig, because of smart pointers (not that I'm implying smart pointers are anywhere near sufficient).
      - brabel 2y ago
        WTH they were talking about Rust and Zig, they did not even mention C++ and you come with "if your metrics is blah then C++ is superior, checkmate!", completely ignoring C++ is a monster of complexity while Zig is basically simple as C.
        Ygg2 2y ago
        If you present an argument that you like X in a thing so you picked B, and A exist that's more X than B, it means your argument is partially (you like X and Z) or totally (you like Y) wrong. In this context of, if you are using Zig for its safety via tooling, there is a much more mature candidate C++.
        brabel 2y ago
        That's exactly what I was criticizing: you just make the unfounded assumption that "argument that you like X" is the only thing that matters, and the debate is not only about X in the context of languages A and B. Introducing C to the debate is stupid, as then the obvious answer is just "but C has Y which is horrile" and so on.
    - dolmen 2y ago
      In related news, someone just published a PoC borrow checker for Zig: https://news.ycombinator.com/item?id=42923829 https://news.ycombinator.com/item?id=42923829
  - ulbu 2y ago
    the barrier between unsafe and safe has additional rules. it’s not “just dropping to unsafe” – you need to make sure you leave it safely.
- baranul 2y ago
  Various modern alternative languages can claim to be "safe enough" or safer than C, along with C interop. Nim, Dlang... In fact, the V programming language (Vlang) can make the argument of being even safer, because it has more default safety features and an optional GC (that no libraries depend on) for greater memory safety. That and it being designed to be easier to use and learn, for general-purpose programming. The article, in its review of the Zig language, goes after its marketing history and broken promises (calling Andrew's statements fallacious and worse) for attempting to portray itself as safer than unsafe Rust, the distortions around UB (undefined behavior), etc... As a consequence of the demonstrably valid test results and being tired of unreliability, the author stopped using Zig. It should also be mentioned, that v1 Zig is nowhere in sight, so likely many years more to wait.
ulbu 2y ago
i haven’t seen anyone pronounce it anywhere once.

This is absolutely not what the article is about. A good majority of it is spent on the myth that Zig is safer than Rust, which has nothing to do with wishing Zig was more like Rust.

chrisco255 2y ago

Is there a myth that makes that claim? Virtually every take I've heard is that Zig is "safe enough" while giving developers more control over memory and actually, it's specifically better for cases where you must write unsafe code, as it's not possible to express all programs in safe Rust.

bobbylarrybobby 2y ago
If you must write unsafe code, what's wrong with just dropping down to unsafe in Rust when you need to? You have all the power unsafe provides, and you have a smaller surface area to audit than if your entire codebase resides in one big unsafe block.
- chrisco255 2y ago
  Unsafe Rust is problematic: https://zackoverflow.dev/writing/unsafe-rust-vs-zig https://zackoverflow.dev/writing/unsafe-rust-vs-zig See also: https://github.com/roc-lang/roc/blob/main/www/content/faq.md#why-does-roc-use-both-rust-and-zig-rust-and-zig https://github.com/roc-lang/roc/blob/main/www/content/faq.md... Zig is not entirely unsafe. It provides quite a few compile time checks and primitives to catch memory leaks or prevent them altogether.
  - oneshtein 2y ago
    Yes, unsafe code is problematic in Rust, C, C++, etc. Is Zig different?
    - mk12 2y ago
      It’s harder to write correct unsafe Rust than correct Zig because (1) Rust uses references all over the place, but when writing unsafe code you must scrupulously avoid “producing” an invalid reference (even if you never deference it), and (2) there’s lots of syntax noise which obscures what the code is doing (though &raw is a step in the right direction).
      - zozbot234 2y ago
        > Rust uses references all over the place This is mostly a concern with the Rust stdlib, though. And it's in principle fixable, by writing new varieties of those stdlib functions that take raw-pointer or &UnsafeCell<...> arguments, and delegating the "safe" varieties to those.
        kprotty 2y ago
        There's compiler-level traits like `Iterator` and `Future` which enforce references. If wanting to do intrusive pointers into them, one risks creating overlapping references: https://github.com/tokio-rs/tokio/issues/3399 https://github.com/tokio-rs/tokio/issues/3399
        zozbot234 2y ago
        References to UnsafeCell<> should still be safe, because the only thing you can do with an &UnsafeCell<T> is extract a possibly-mutating raw pointer to T. (UnsafeCell<> is also special in that, like Cell<>, you can mutate through it without incurring UB.)
      - oneshtein 2y ago
        For Rust references, rules[0] are not hard to follow: The pointer must be properly aligned. It must be non-null. It must be “dereferenceable”: a pointer is dereferenceable if the memory range of the given size starting at the pointer is entirely contained within the bounds of that allocated object. Note that in Rust, every (stack-allocated) variable is considered a separate allocated object. The pointer must point to a valid value of type T. When creating a mutable reference, then while this reference exists, the memory it points to must not get accessed (read or written) through any other pointer or reference not derived from this reference. When creating a shared reference, then while this reference exists, the memory it points to must not get mutated (except inside UnsafeCell). [0]: https://doc.rust-lang.org/stable/core/ptr/index.html#pointer-to-reference-conversion https://doc.rust-lang.org/stable/core/ptr/index.html#pointer...
  - zamalek 2y ago
    This is precisely the myth that the article talks about. Miri finds significantly more UB in unsafe Rust than Zig's checks do. Even if it weren't, this exaggeration is a complete theater. You aren't supposed to use unsafe Rust unless you really have to. I have been using Rust since 2020 and I've used it once, for 3 lines of code. The entirety of all Zig codebases is unsafe. That's fine if you are fine with unsafe code, but this myth is dishonest, and I take great issue with using a language where the founder is the primary source of the dishonesty - because what else is being swept under the rug?
    - throwawaymaths 2y ago
      yes but by the time you're using miri, why not just run zig with a separate static checker that does all the memory safety parts? https://github.com/ityonemo/clr https://github.com/ityonemo/clr
      - pcwalton 2y ago
        For one, it doesn't do all the "memory safety parts", according to the readme. I'm very skeptical that Zig can be made memory safe with a checker while still remaining compatible with existing code. Certainly neither C nor C++ can, and Zig isn't meaningfully different in expressivity (if anything, it's more expressive, which is the opposite of what you want).
        throwawaymaths 2y ago
        FTrepo: Q: You didn't do X, so Zig will never be able to track X A: Maybe. Only way to know for sure is to fork this (or, hopefully, a 'real' successor) and fail. However, consider that "trivially" it should be possible to externally annotate every zig file with lifetime/type annotations identical to that of Rust and run "exactly the same" analysis as Rust and get the same memory safety as Rust. it appears the clr author anticipated you: you didnt fork it, try, and fail, so you have ceded the authority to credibly make your speculative complaint > Zig isn't meaningfully different in expressivity it is meaningfully different in expressivity at the AIR level. AIR looks nothing like c, c++, zig, or rust.
  - pcwalton 2y ago
    > It provides quite a few compile time checks and primitives to catch memory leaks or prevent them altogether. From what I've seen, clang has all of these and more for C++. If your metric is "tooling to help you catch UB", C++ is significantly superior to Zig.
    - chrisco255 2y ago
      Zig has a C and C++ compiler built into it and works seamlessly with it. Several C/C++ projects use Zig as a build tool. Zig makes different trade-offs with C++ from a language design standpoint. C++ has a lot more footguns to create UB in the first place.
      - pcwalton 2y ago
        > C++ has a lot more footguns to create UB in the first place. I'd actually give the edge to C++ over Zig, because of smart pointers (not that I'm implying smart pointers are anywhere near sufficient).
    - brabel 2y ago
      WTH they were talking about Rust and Zig, they did not even mention C++ and you come with "if your metrics is blah then C++ is superior, checkmate!", completely ignoring C++ is a monster of complexity while Zig is basically simple as C.
      - Ygg2 2y ago
        If you present an argument that you like X in a thing so you picked B, and A exist that's more X than B, it means your argument is partially (you like X and Z) or totally (you like Y) wrong. In this context of, if you are using Zig for its safety via tooling, there is a much more mature candidate C++.
        brabel 2y ago
        That's exactly what I was criticizing: you just make the unfounded assumption that "argument that you like X" is the only thing that matters, and the debate is not only about X in the context of languages A and B. Introducing C to the debate is stupid, as then the obvious answer is just "but C has Y which is horrile" and so on.
  - dolmen 2y ago
    In related news, someone just published a PoC borrow checker for Zig: https://news.ycombinator.com/item?id=42923829 https://news.ycombinator.com/item?id=42923829
- ulbu 2y ago
  the barrier between unsafe and safe has additional rules. it’s not “just dropping to unsafe” – you need to make sure you leave it safely.
baranul 2y ago
Various modern alternative languages can claim to be "safe enough" or safer than C, along with C interop. Nim, Dlang... In fact, the V programming language (Vlang) can make the argument of being even safer, because it has more default safety features and an optional GC (that no libraries depend on) for greater memory safety. That and it being designed to be easier to use and learn, for general-purpose programming. The article, in its review of the Zig language, goes after its marketing history and broken promises (calling Andrew's statements fallacious and worse) for attempting to portray itself as safer than unsafe Rust, the distortions around UB (undefined behavior), etc... As a consequence of the demonstrably valid test results and being tired of unreliability, the author stopped using Zig. It should also be mentioned, that v1 Zig is nowhere in sight, so likely many years more to wait.

ulbu 2y ago

i haven’t seen anyone pronounce it anywhere once.