4 ms·

> memory safety is simply table stakes Why? And also, this is black and white thinking, implying that "swift and rust" are completely memory "safe" and zig is

> memory safety is simply table stakes Why? And also, this is black and white thinking, implying that "swift and rust" are completely memory "safe" and zig is completely "unsafe". It's a spectrum. The real underlying comparison statement here is far more subjective. It's along the lines of: "I find it easier to write solid code in rust than in zig". This is a more accurate and fair way to state the semantics of what you are saying. Saying things like "rust is memory safe. Zig is not memory safe" is reductionist and too absolutist.

Barrin92 1y ago
>Why? Memory bugs are hard to debug, potentially catastrophic (particularly concerning security) and in large systems software tend to constitute the majority of issues.[1] It is true that Rust is not absolutely memory safe and Zig provides some more features than C but directionally it is correct that Rust (or languages with a similar design philosophy) eliminate billion dollar mistakes. And you can take that literally rather than metaphorically. We live in a world where vulnerable software can take a country's infrastructure out. [1] https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
DarkNova6 1y ago
If decades of experience shows us anything it is that discipline and skill is not enough to achieve memory safety. Developers simply aren’t as good at dealing with these problems as they think they are. And even if a few infallible individuals would be truly flawless, their co-workers just aren’t.
- scuff3d 1y ago
  I'm not convinced that on average Zig is any less safe, or produces software that is any less stable, then Rust. Zig embraces reality in its design. Allocation exist, hardware exists, our entire modern infrastructure is built on C. When you start to work directly with those things, there is going to be safety issues. That's just how it is. Zig tries to give you as many tools as possible to make good decisions at every turn, and help you catch mistakes. Like it's testing allocator detecting memory leaks. Rust puts you in a box, where the outside world doesn't exist. As long as you play by its rules everything will be fine. But it eventually has to deal with this stuff, so it has unsafe. I suspect if Rust programmers went digging through all their dependencies, especially when they are working on low level stuff, they would be surprised by how much of it actually exists. Zig tried to be more safe on average and make developers aware if pitfalls. Rust tried to be 100% safe where it can, and then not safe at all where it can't. Obviously Rusts approach has worked for it, but I don't think that invalidates Zigs. Especially when you start to get into projects where a lot of unsafe operations are needed. Zig also has an advantage in that it simplifies memory management through its use of allocators. If you read Richard Feldman's write up on the Roc compilers rewtire in Zig, he talks about how he realized their memory allocation patterns were simple enough in Zig that they just didn't need the complexity of Rust.
  - vacuity 1y ago
    To be clear, Rust encourages the development of safe abstractions around unsafe code, so that the concern goes from proportion of unsafe to encapsulation of unsafe. Whether you trust some library author to encapsulate their unsafe is, I think, reducible to whether you trust a library author to write a good library. Unsafe is not all-or-nothing. Thus, as with all languages, good general programming practices come before language features.
    - scuff3d 1y ago
      That's kind of my point. Because it's isolated and abstracted I wouldn't be surprised if most Rust devs have no idea how much unsafe code is actually out there. Rust does not want you to think about memory management. You play by its rules and let it worry about allocations/deallocation. Frankly in that regard Rust has more in common with GC languages than it does Zig or C. Zig chooses to give the developer full control and provides tools to make writing correct/safe code easier.
      - vacuity 1y ago
        Although not a comprehensive report, people tend to count the source lines of unsafe in a Rust codebase as a metric. Moreover, reputable libraries worth using typically take care to reduce unsafe, and where it is used, encapsulate it well. I don't think you have a substantive point on the matter. Unsafe certainly can be abused, but it's not a bogeyman that people scarcely catch glimpses of. Unsafe doesn't demote the safety of Rust to that of C, or something like that. Your comments on Rust's philosophy towards memory management are off base. Rust is unlike GC languages, even Swift, in that it makes allocations and deallocations explicit. For example, I know that one approach to implementing async functions in trait objects was rejected because it would've made implicit heap allocations. Granted, Rust is far behind on reified and custom allocators. Rust has functionality to avoid the default alloc crate, which is the part of libstd that does heap allocations, and a library ecosystem for alternate data structures. Rust doesn't immediately give you total access, but it's only a few steps away. Could it be easier to work with? Absolutely. The same goes for unsafe.
dmit 1y ago
>> memory safety is simply table stakes > Why? Because it's a stepping stone to other kinds of safety. Memory safety isn't the be-all and end-all, but it gets us to where we can focus other important things. And turns out in this particular case we don't even have to pay much for it in terms of performance. > The real underlying comparison statement here is far more subjective. It's along the lines of: "I find it easier to write solid code in rust than in zig". Agreed! But also how about "We can get pretty close to memory safety with the tools we provide! Mostly at runtime! If you opt-in!" ~~ signed, people (Zig compiler itself, Bun, Ghostty, etc) who ship binaries built with -Doptimize=ReleaseFast

Barrin92 1y ago

>Why? Memory bugs are hard to debug, potentially catastrophic (particularly concerning security) and in large systems software tend to constitute the majority of issues.[1] It is true that Rust is not absolutely memory safe and Zig provides some more features than C but directionally it is correct that Rust (or languages with a similar design philosophy) eliminate billion dollar mistakes. And you can take that literally rather than metaphorically. We live in a world where vulnerable software can take a country's infrastructure out. [1] https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

DarkNova6 1y ago

If decades of experience shows us anything it is that discipline and skill is not enough to achieve memory safety. Developers simply aren’t as good at dealing with these problems as they think they are. And even if a few infallible individuals would be truly flawless, their co-workers just aren’t.

scuff3d 1y ago
I'm not convinced that on average Zig is any less safe, or produces software that is any less stable, then Rust. Zig embraces reality in its design. Allocation exist, hardware exists, our entire modern infrastructure is built on C. When you start to work directly with those things, there is going to be safety issues. That's just how it is. Zig tries to give you as many tools as possible to make good decisions at every turn, and help you catch mistakes. Like it's testing allocator detecting memory leaks. Rust puts you in a box, where the outside world doesn't exist. As long as you play by its rules everything will be fine. But it eventually has to deal with this stuff, so it has unsafe. I suspect if Rust programmers went digging through all their dependencies, especially when they are working on low level stuff, they would be surprised by how much of it actually exists. Zig tried to be more safe on average and make developers aware if pitfalls. Rust tried to be 100% safe where it can, and then not safe at all where it can't. Obviously Rusts approach has worked for it, but I don't think that invalidates Zigs. Especially when you start to get into projects where a lot of unsafe operations are needed. Zig also has an advantage in that it simplifies memory management through its use of allocators. If you read Richard Feldman's write up on the Roc compilers rewtire in Zig, he talks about how he realized their memory allocation patterns were simple enough in Zig that they just didn't need the complexity of Rust.
- vacuity 1y ago
  To be clear, Rust encourages the development of safe abstractions around unsafe code, so that the concern goes from proportion of unsafe to encapsulation of unsafe. Whether you trust some library author to encapsulate their unsafe is, I think, reducible to whether you trust a library author to write a good library. Unsafe is not all-or-nothing. Thus, as with all languages, good general programming practices come before language features.
  - scuff3d 1y ago
    That's kind of my point. Because it's isolated and abstracted I wouldn't be surprised if most Rust devs have no idea how much unsafe code is actually out there. Rust does not want you to think about memory management. You play by its rules and let it worry about allocations/deallocation. Frankly in that regard Rust has more in common with GC languages than it does Zig or C. Zig chooses to give the developer full control and provides tools to make writing correct/safe code easier.
    - vacuity 1y ago
      Although not a comprehensive report, people tend to count the source lines of unsafe in a Rust codebase as a metric. Moreover, reputable libraries worth using typically take care to reduce unsafe, and where it is used, encapsulate it well. I don't think you have a substantive point on the matter. Unsafe certainly can be abused, but it's not a bogeyman that people scarcely catch glimpses of. Unsafe doesn't demote the safety of Rust to that of C, or something like that. Your comments on Rust's philosophy towards memory management are off base. Rust is unlike GC languages, even Swift, in that it makes allocations and deallocations explicit. For example, I know that one approach to implementing async functions in trait objects was rejected because it would've made implicit heap allocations. Granted, Rust is far behind on reified and custom allocators. Rust has functionality to avoid the default alloc crate, which is the part of libstd that does heap allocations, and a library ecosystem for alternate data structures. Rust doesn't immediately give you total access, but it's only a few steps away. Could it be easier to work with? Absolutely. The same goes for unsafe.

dmit 1y ago

>> memory safety is simply table stakes > Why? Because it's a stepping stone to other kinds of safety. Memory safety isn't the be-all and end-all, but it gets us to where we can focus other important things. And turns out in this particular case we don't even have to pay much for it in terms of performance. > The real underlying comparison statement here is far more subjective. It's along the lines of: "I find it easier to write solid code in rust than in zig". Agreed! But also how about "We can get pretty close to memory safety with the tools we provide! Mostly at runtime! If you opt-in!" ~~ signed, people (Zig compiler itself, Bun, Ghostty, etc) who ship binaries built with -Doptimize=ReleaseFast