5 ms·

"A less rigorous Rust" is in some ways what Zig is trying to be, although that's not the only thing that differentiates the two languages.

torginus 1y ago
Not in the sense I meant to make the comparison - Zig doesn't even pretend to do memory safety - if you don't free something manually it won't get freed - this is way worse level of safety than even what C++ with unique_ptr. In contrast if Rust only ensured that a reference doesn't outlive the scope it's valid in (allocated and cleaned up via RAII), a lot of problems with Rust would go away, like you could have 2 mutable references pointing to the same thing - it'd still be leak free, but you could have data races, and would need some aliasing heuristics like you have in C. Still most of the complaining of the borrow checker would go away. Imo this is an idea worth exploring in a language, but I'm sure doing this would upset Rust purists.
- benji-york 1y ago
  > Zig doesn't even pretend to do memory safety - if you don't free something manually it won't get freed Preventing memory leaks isn't normally what people mean by "memory safety". As an aside: a common memory management approach used in Zig is to have a dedicated memory pool for an operation and simply free all of the memory after the operation is over instead of freeing individual allocations.
  - JuniperMesos 1y ago
    > Preventing memory leaks isn't normally what people mean by "memory safety". People do sometimes expect it to be encompassed by memory safety, even though the Rust documentation clearly states that it does not prevent memory leaks in safe code and offers several obvious ways to deliberately leak memory.
- pron 1y ago
  > Zig doesn't even pretend to do memory safety This is simply untrue. Zig offers the same spatial memory safety as Rust does, and that is the kind of memory safety that prevents more dangerous vulnerabilities [1] than the kind Rust offers and Zig doesn't (temporal memory safety). > if you don't free something manually it won't get freed Rust also isn't free of memory leaks, and doesn't even pretend to guarantee that all allocations are freed. Lack of memory leaks doesn't fall under what Rust defines as memory safety (which Rust defines as guarantees it does provide, excluding those it doesn't). [1]: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html - Rust and Zig's memory safety prevent #2 and #6 on the list. Rust, additionally, prevents #8. C prevents none of those.
  - torginus 1y ago
    You're responding to the emotional appeal part of my post, not the argument itself - I'm sorry for including it, as it had sidetracked the useful conversation. Zig doesn't have the memory safety mechanisms of C++ level shared_ptr/unique_ptr. It's essentially C's malloc/free with the added safety of defer (or possibly arenas), but making sure that the program doesn't leak memory (or have use-after-free bugs) falls on the programmer. And memory leaks are a much lesser problem, as they usually lead to crashes in OoM situation, than gaining access to random blocks of memory. Besides, the way you trigger memory leaks in Rust/C++ is with circular references, which are much harder to create than just missing a free() somewhere. If you have memory that's not tied to a function scope's lifetime in Zig (or the scope of an allocator), then you're essentially have to go by C rules
    - pron 1y ago
      > Zig doesn't have the memory safety mechanisms of C++ level shared_ptr/unique_ptr. Zig's memory-safety is spatial, which is the more dangerous kind. Your examples are all temporal, and I don't know if I would call them "safety" as the language doesn't enforce or even encourage their use. For example, I work on one of the world's most foundational C++ projects (the HotSpot virtual machine), where neither shared_ptr nor unique_ptr are used at all; the language doesn't complain. There are reference-counted pointer libraries for Zig, too (although I don't think they're popular). > It's essentially C's malloc/free with the added safety of defer No, it isn't. First, unlike C or C++, it offers Rust-like spatial memory safety (again, the more important kind). Second, allocation in Zig is much more explicit than in C or C++. > Besides, the way you trigger memory leaks in Rust/C++ is with circular references, which are much harder to create than just missing a free() somewhere. They're also much harder to detect, especially when you have a very explicit memory allocation scheme. > If you have memory that's not tied to a function scope's lifetime in Zig (or the scope of an allocator), then you're essentially have to go by C rules Again, Zig doesn't seek to offer temporal memory safety, but it does offer the same level of spatial memory safety as Rust does, and while the "rules" of temporal management are similar to C, the way allocation works in Zig makes for a very different experience. An allocating function in Zig looks very different from its C counterpart. Zig rejects the temporal memory management schemes of C, C++, and Rust - each for different reasons - and prefers a different kind. Of those, only Rust offers temporal memory safety (in the sense that it's controlled by the language) - albeit for a price - and the rest don't.

torginus 1y ago

Not in the sense I meant to make the comparison - Zig doesn't even pretend to do memory safety - if you don't free something manually it won't get freed - this is way worse level of safety than even what C++ with unique_ptr. In contrast if Rust only ensured that a reference doesn't outlive the scope it's valid in (allocated and cleaned up via RAII), a lot of problems with Rust would go away, like you could have 2 mutable references pointing to the same thing - it'd still be leak free, but you could have data races, and would need some aliasing heuristics like you have in C. Still most of the complaining of the borrow checker would go away. Imo this is an idea worth exploring in a language, but I'm sure doing this would upset Rust purists.

benji-york 1y ago
> Zig doesn't even pretend to do memory safety - if you don't free something manually it won't get freed Preventing memory leaks isn't normally what people mean by "memory safety". As an aside: a common memory management approach used in Zig is to have a dedicated memory pool for an operation and simply free all of the memory after the operation is over instead of freeing individual allocations.
- JuniperMesos 1y ago
  > Preventing memory leaks isn't normally what people mean by "memory safety". People do sometimes expect it to be encompassed by memory safety, even though the Rust documentation clearly states that it does not prevent memory leaks in safe code and offers several obvious ways to deliberately leak memory.
pron 1y ago
> Zig doesn't even pretend to do memory safety This is simply untrue. Zig offers the same spatial memory safety as Rust does, and that is the kind of memory safety that prevents more dangerous vulnerabilities [1] than the kind Rust offers and Zig doesn't (temporal memory safety). > if you don't free something manually it won't get freed Rust also isn't free of memory leaks, and doesn't even pretend to guarantee that all allocations are freed. Lack of memory leaks doesn't fall under what Rust defines as memory safety (which Rust defines as guarantees it does provide, excluding those it doesn't). [1]: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html - Rust and Zig's memory safety prevent #2 and #6 on the list. Rust, additionally, prevents #8. C prevents none of those.
- torginus 1y ago
  You're responding to the emotional appeal part of my post, not the argument itself - I'm sorry for including it, as it had sidetracked the useful conversation. Zig doesn't have the memory safety mechanisms of C++ level shared_ptr/unique_ptr. It's essentially C's malloc/free with the added safety of defer (or possibly arenas), but making sure that the program doesn't leak memory (or have use-after-free bugs) falls on the programmer. And memory leaks are a much lesser problem, as they usually lead to crashes in OoM situation, than gaining access to random blocks of memory. Besides, the way you trigger memory leaks in Rust/C++ is with circular references, which are much harder to create than just missing a free() somewhere. If you have memory that's not tied to a function scope's lifetime in Zig (or the scope of an allocator), then you're essentially have to go by C rules
  - pron 1y ago
    > Zig doesn't have the memory safety mechanisms of C++ level shared_ptr/unique_ptr. Zig's memory-safety is spatial, which is the more dangerous kind. Your examples are all temporal, and I don't know if I would call them "safety" as the language doesn't enforce or even encourage their use. For example, I work on one of the world's most foundational C++ projects (the HotSpot virtual machine), where neither shared_ptr nor unique_ptr are used at all; the language doesn't complain. There are reference-counted pointer libraries for Zig, too (although I don't think they're popular). > It's essentially C's malloc/free with the added safety of defer No, it isn't. First, unlike C or C++, it offers Rust-like spatial memory safety (again, the more important kind). Second, allocation in Zig is much more explicit than in C or C++. > Besides, the way you trigger memory leaks in Rust/C++ is with circular references, which are much harder to create than just missing a free() somewhere. They're also much harder to detect, especially when you have a very explicit memory allocation scheme. > If you have memory that's not tied to a function scope's lifetime in Zig (or the scope of an allocator), then you're essentially have to go by C rules Again, Zig doesn't seek to offer temporal memory safety, but it does offer the same level of spatial memory safety as Rust does, and while the "rules" of temporal management are similar to C, the way allocation works in Zig makes for a very different experience. An allocating function in Zig looks very different from its C counterpart. Zig rejects the temporal memory management schemes of C, C++, and Rust - each for different reasons - and prefers a different kind. Of those, only Rust offers temporal memory safety (in the sense that it's controlled by the language) - albeit for a price - and the rest don't.