3 ms·

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 exagger

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.
    - Ygg2 2y ago
      > 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 That's a caveat. Not an expectation. Plus that's not how proof works. Neither Zig nor Zig+Clr have really proven they are safe, ergo they are unsafe or possibly safe (respectively).
      - throwawaymaths 2y ago
        wow what are you afraid of. you're working really hard to tear down something that is an incomplete proof of concept.
        zamalek 2y ago
        The original argument is that clr proves Zig is as safe as Rust, per your wording " all the memory safety parts." Does the incompletely POC do all the parts, or doesn't it? That is no criticism against the project itself, striving to improve memory safety in any language is an honorable goal. The cinch is that an incomplete POC doesn't prove things one way or another, the POC needs to be completed (or at least completed far enough to prove your point). It either matches or exceeds Rust memory safety, or it only vastly improves Zig memory safety. Both are great outcomes, for what it's worth. It shouldn't have been shown as an example of how Zig is just as/more safe than Rust if it is not. Mispresenting the project tears it down, not questioning its use an an example. Just like misrepresenting Zig's safety (and Rust's unsafety) tears Zig down.
        throwawaymaths 2y ago
        I guess the question is what level of satisfied are you. Are you satisfied like "proof is left as an exercise for the reader" in a math textbook? Or is it like "I have proved this but it's too large to fit in the margins"? It seems author couldn't be bothered to complete it since there's (minor) missing features in the zig compiler that need to be satisfied first to make it worthwhile?
chrisco255 2y ago
> Miri finds significantly more UB in unsafe Rust than Zig's checks do. That's not a substantiated claim. Miri also runs very slowly. > 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. Cool, glad you haven't needed it. If you're ever writing interpreters or interfacing with external code, you'll need it. > The entirety of all Zig codebases is unsafe Zig is not 100% memory safe but it has compile-time safety features for vast majority of problems developers get themselves into with C/C++. Meanwhile, Rust's safety overhead has real trade-offs in terms of developer productivity, computational performance, compiler performance and binary size.
- zamalek 2y ago
  > That's not a substantiated claim. The article we are commenting on substantiates it with, several, actual examples. > interpreters In what world do interpreters require unsafe code? A naive interpreter that recursively descends an AST doesn't need it, and a bytecode interpreter doesn't need it either. You'll probably need it if you want to make a fast GC, but that does not mean your entire codebase has to be unsafe. > interfacing with external code This is one reason unsafe exists, yes. You are supposed to hide the unsafe parts behind a safe interface. For example, Rust unavoidably has to deal with external code to do I/O - yet, the exposed std::fs interface is safe. This is a well established doctrine in the Rust community, and at least one prominent project has received hot hell for ignoring it. And, again, the portions of code that are unsafe in a Rust codebase - even when required - are supposed to be minimal, well contained, and well tested. Running a suite of tests to check a small amount of code under Miri is not prohibitive at all. If someone is going to insist on using unsafe across their codebase then, yes, they are far better served by using a language that is unsafe to begin with. I have done embedded Rust, and even there I have largely avoided unsafe code (the 3 lines I was forced to write happened to be for embedded). > Rust's safety overhead has real trade-offs [...] I never claimed otherwise. Those trade-offs have a purpose: fewer degrees of freedom result in higher degrees of certainty. Even Rust has too many degrees of freedom[1], but we don't sweep that under the rug, deflect it, or outright lie about the situation. The Rust zeitgeist largely agrees your opinion (or rather: Andrew's opinion) of unsafe Rust, in a very oblique way. It's shit, we don't like using it. It is certainly not an accurate summary of Rust as a whole. Leveraging unsafe Rust against Rust as a whole is a dishonest line of thinking and I'm not going to engage with it further. [1]: https://github.com/Speykious/cve-rs https://github.com/Speykious/cve-rs

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.
  - Ygg2 2y ago
    > 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 That's a caveat. Not an expectation. Plus that's not how proof works. Neither Zig nor Zig+Clr have really proven they are safe, ergo they are unsafe or possibly safe (respectively).
    - throwawaymaths 2y ago
      wow what are you afraid of. you're working really hard to tear down something that is an incomplete proof of concept.
      - zamalek 2y ago
        The original argument is that clr proves Zig is as safe as Rust, per your wording " all the memory safety parts." Does the incompletely POC do all the parts, or doesn't it? That is no criticism against the project itself, striving to improve memory safety in any language is an honorable goal. The cinch is that an incomplete POC doesn't prove things one way or another, the POC needs to be completed (or at least completed far enough to prove your point). It either matches or exceeds Rust memory safety, or it only vastly improves Zig memory safety. Both are great outcomes, for what it's worth. It shouldn't have been shown as an example of how Zig is just as/more safe than Rust if it is not. Mispresenting the project tears it down, not questioning its use an an example. Just like misrepresenting Zig's safety (and Rust's unsafety) tears Zig down.
        throwawaymaths 2y ago
        I guess the question is what level of satisfied are you. Are you satisfied like "proof is left as an exercise for the reader" in a math textbook? Or is it like "I have proved this but it's too large to fit in the margins"? It seems author couldn't be bothered to complete it since there's (minor) missing features in the zig compiler that need to be satisfied first to make it worthwhile?

chrisco255 2y ago

> Miri finds significantly more UB in unsafe Rust than Zig's checks do. That's not a substantiated claim. Miri also runs very slowly. > 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. Cool, glad you haven't needed it. If you're ever writing interpreters or interfacing with external code, you'll need it. > The entirety of all Zig codebases is unsafe Zig is not 100% memory safe but it has compile-time safety features for vast majority of problems developers get themselves into with C/C++. Meanwhile, Rust's safety overhead has real trade-offs in terms of developer productivity, computational performance, compiler performance and binary size.

zamalek 2y ago
> That's not a substantiated claim. The article we are commenting on substantiates it with, several, actual examples. > interpreters In what world do interpreters require unsafe code? A naive interpreter that recursively descends an AST doesn't need it, and a bytecode interpreter doesn't need it either. You'll probably need it if you want to make a fast GC, but that does not mean your entire codebase has to be unsafe. > interfacing with external code This is one reason unsafe exists, yes. You are supposed to hide the unsafe parts behind a safe interface. For example, Rust unavoidably has to deal with external code to do I/O - yet, the exposed std::fs interface is safe. This is a well established doctrine in the Rust community, and at least one prominent project has received hot hell for ignoring it. And, again, the portions of code that are unsafe in a Rust codebase - even when required - are supposed to be minimal, well contained, and well tested. Running a suite of tests to check a small amount of code under Miri is not prohibitive at all. If someone is going to insist on using unsafe across their codebase then, yes, they are far better served by using a language that is unsafe to begin with. I have done embedded Rust, and even there I have largely avoided unsafe code (the 3 lines I was forced to write happened to be for embedded). > Rust's safety overhead has real trade-offs [...] I never claimed otherwise. Those trade-offs have a purpose: fewer degrees of freedom result in higher degrees of certainty. Even Rust has too many degrees of freedom[1], but we don't sweep that under the rug, deflect it, or outright lie about the situation. The Rust zeitgeist largely agrees your opinion (or rather: Andrew's opinion) of unsafe Rust, in a very oblique way. It's shit, we don't like using it. It is certainly not an accurate summary of Rust as a whole. Leveraging unsafe Rust against Rust as a whole is a dishonest line of thinking and I'm not going to engage with it further. [1]: https://github.com/Speykious/cve-rs https://github.com/Speykious/cve-rs