4 ms·

Zig is less memory safe than Rust, but more than C/C++. Neither Zig nor Rust is fundamentally memory safe.

• Ar-Curunir 1y ago
  What? Zig is definitively not memory-safe, while safe Rust, is, by definition, memory-safe. Unsafe rust is not memory-safe, but you generally don't need to have a lot of it around.
  • ummonk 1y ago
    Safe Rust is demonstrably not memory-safe: https://github.com/Speykious/cve-rs/tree/main https://github.com/Speykious/cve-rs/tree/main
    • steveklabnik 1y ago
      This is a compiler bug. This has no bearing on the language itself. Bugs happen, and they will be fixed, even this one.
      • ummonk 1y ago
        It's a 10 year old bug which will eventually be fixed but may require changes to how Rust handles type variance. Until you guys write an actual formal specification, the compiler is the language.
        • steveklabnik 1y ago
          It’s a ten year old bug because it has never been found in the wild, ever, in those ten years. Low impact, high implementation effort bugs take less priority than bugs that affect real users. The project is adopting Ferrocene for the spec.
          • ummonk 1y ago
            Ferrocene is intended to document the behavior of the current version of the rustc compiler, so it's just an effort to formalize "the compiler is the language". Yes, the soundness hole itself is low impact and doesn't need to be prioritized but it undermines the binary "Zig is definitively not memory-safe, while safe Rust, is, by definition, memory-safe" argument that was made in response to me. Now you're dealing with qualitative / quantitative questions of practical impact, in which my original statement holds: "Zig is less memory safe than Rust, but more than C/C++. Neither Zig nor Rust is fundamentally memory safe." You can of course declare that Safe Rust is by definition memory safe, but that doesn't make it any more true than declaring that Rust solves the halting problem or that it proves P=NP. RustBelt is proven sound. Rust by contrast, as being documented by Ferrocene, is currently fundamentally unsound (though you won't hit the soundness issues in practice).
            • _flux 1y ago
              I believe these two statements should show the fundamental difference: - If a safe Rust program exhibits a memory safety problem, it is a bug in the Rust compiler that is to be fixed - If a Zig program exhibits a memory safety problem, it is a bug in the Zig program that needs to be fixed, not in the compiler Wouldn't you agree? > Ferrocene is intended to document the behavior of the current version of the rustc compiler, so it's just an effort to formalize "the compiler is the language". I must admit I haven't read the specification, but I doubt they attempt to be "bug for bug" compatible in the sense that the spec enumerates memory safety bugs present in the Rust compiler. But am I then mistaken?
              • ummonk 1y ago
                No, I don't agree. A compiler bug is something that gets fixed in a patch release after it's reported, or perhaps some platform-specific regression that gets fixed in the next release after it's reported. What we're discussing by contrast is a soundness hole in the language itself - one which will most likely require breaking changes to the language to close (i.e. some older programs that were perfectly safe will fail to compile as a side effect of tightening up the Rust language to prevent this soundness hole). As to the Ferrocene specification, it explicitly states "Any difference between the FLS and the behavior of the Rust compiler is considered an error on our part and the FLS will be updated accordingly." Proposals to fix the soundness hole in Rust either change the variance rules themselves, or require where clauses in certain places. Either of these changes would require corresponding changes to chapter 4 of the Ferrocene specification.
        • deleted 1y ago
          [deleted]
  • Graziano_M 1y ago
    The second you have any `unsafe`, Rust is _by definition_ not memory-safe.
    • Ar-Curunir 1y ago
      By that definition, Python is not memory-safe, Java is not memory-safe, Go is not memory-safe, and so on. All of these languages contain escape hatches to do memory-unsafe stuff, yet no one is calling them memory unsafe.
      • ummonk 1y ago
        Go is more memory unsafe than Java or Rust. Data races in concurrent Go code can cause memory corruption, unlike in concurrent Java code. Safe Rust is designed to avoid data races altogether using static analysis.
    • Meneth 1y ago
      And the majority of the Rust standard library uses `unsafe`.
      • Measter 1y ago
        Prove it. Show me the stats that the standard library is over 50% unsafe.
        • 9rx 1y ago
          "Over 50%" only holds if the statement is intended to be binary. It may be that he considers direct use, no use, and transitive use to be all different. In which case it is possible that the majority[1] use unsafe, even if more than 50% does not. [1] The cult of the orange man would call this a plurality, which may be what has tripped you up, but the civilized world calls it a majority.
  • rurban 1y ago
    By definition yes. There were a lot of lies to persuade managers. You can write a lot into your documentation. But by implementation and spec definitely not.