5 ms·

> Zig is safer than C++ Maybe if someone bends over backwards to rationalize it, but not in any real sense. Zig doesn't have automatic memory management or mov

> Zig is safer than C++ Maybe if someone bends over backwards to rationalize it, but not in any real sense. Zig doesn't have automatic memory management or move semantics. In C++ you can put bounds checking in your data structures and it is already in the standard data structures. You can't build RAII and moves into zig.

pron 1y ago
> Maybe if someone bends over backwards to rationalize it, but not in any real sense. In a simple, real sense. Zig prevents out-of-bounds access just as Rust does; C++ doesn't. Interestingly, almost all of Rust's complexity is invested in the less dangerous kind of memory unsafety (https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html). > You can't build RAII and moves into zig. So RAII is part of the definition of memory safety now? Why not just declare memory safety to be "whatever Rust does", say that anything that isn't exactly that is worthless, and be done with that, since that's the level of the arguments anyway. We could, of course, argue over which of Rust, Zig, and C++ offers the best contribution to correctness beyond the sound guarantees they make, except these are empirical arguments with little empirical data to make any determination, which is part of my point. Software correctness is such a complicated topic and, if anything, it's become more, not less, mysterious over the decades (see Tony Hoare's astonishment that unsound methods have proven more effective than sound methods in many regards). It's now understood to be a complicated game of confidence vs cost that depends on a great many factors. Those who claim to have definitive solutions don't know what they're talking about (or are making unfounded extrapolations).
- CyberDildonics 1y ago
  C++ doesn't. Then why do my data structures detect if I go out of bounds? Interestingly, almost all of Rust's complexity is invested in the less dangerous kind of memory unsafety I didn't say anything about rust. So RAII is part of the definition of memory safety now? Yes. You can clean up memory allocations automatically with destructors and have value semantics for memory that is on the heap. Why not just declare memory safety to be "whatever Rust does", say that anything that isn't exactly that is worthless, and be done with that, since that's the level of the arguments anyway. Why are you talking about rust here? Focus on what I'm saying. We could, of course, argue over which of Rust, Zig, and C++ if anything, it's become more, not less, mysterious over the decades Says who? I don't care about rust or zig, I'm saying that these are solved problems in C++ and I don't have to deal with them. Zig does not have destructors and move semantics.
  - pron 1y ago
    > Then why do my data structures detect if I go out of bounds? I didn't mean you can't write C++ code that enforces that, I said C++ itself doesn't enforce it. > Yes. You can clean up memory allocations automatically with destructors and have value semantics for memory that is on the heap. Surely there are other ways to do that. E.g. Zig has defer. You can say that you may forget to write defer, which is true, but the implicitness of RAII has cause (me, at least) many problems over the years. It's a pros-and-cons thing, and Zig chooses the side of explicitness. > Why are you talking about rust here? Focus on what I'm saying. You're right, sorry :) > Says who? Says most people in the field of software correctness (and me https://pron.github.io https://pron.github.io). In the seventies, the prevalent opinion was that proofs of correctness would be the only viable approach to correctness. Since then, we've learnt two things, both of which were surprising. The first was new results in the computational complexity of model checking (not to be confused with the computational complexity of model checkers; we're talking about the intrinsic computation complexity of the model checking problem, i.e. the problem of knowing whether a program satisfies some correctness property, regardless of how we learn that). This included results (e.g. by Philippe Schnoebelen) showing that even though there would be the reasonable expectation that language abstractions could make the problem easier, even in the worst case - it doesn't. The second was that unsound techniques, including engineering best practices, have proven far more effective than was thought possible in the seventies. This came as quite a shock to formal methods people (most famously, Tony Hoare, who wrote a famous paper about it). As a result, the field of software correctness has shifted its main focus from proving program correct to finding interesting confidence/cost tradeoffs to reduce the number of bugs, realising that there's no single best path to more correctness (as far as we know today). > I'm saying that these are solved problems in C++ and I don't have to deal with them. Zig does not have destructors and move semantics. That's true, but these are not memory safety guarantees. These are mechanisms that could mitigate bugs (though perhaps cause others), and Zig has other, different mechanisms to mitigate bugs (though perhaps cause others). E.g. see how easy it is to write a type-safe printf in Zig compared to C++, or how Zig handles various numeric overflow issues compared to C++. So it's true that C++ has some features we may find helpful that Zig doesn't and vice-versa, we can't judge which of them leads to more correct programs. All I said was that Zig offers more safety guarantees than C++, which it does.

pron 1y ago

> Maybe if someone bends over backwards to rationalize it, but not in any real sense. In a simple, real sense. Zig prevents out-of-bounds access just as Rust does; C++ doesn't. Interestingly, almost all of Rust's complexity is invested in the less dangerous kind of memory unsafety (https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html). > You can't build RAII and moves into zig. So RAII is part of the definition of memory safety now? Why not just declare memory safety to be "whatever Rust does", say that anything that isn't exactly that is worthless, and be done with that, since that's the level of the arguments anyway. We could, of course, argue over which of Rust, Zig, and C++ offers the best contribution to correctness beyond the sound guarantees they make, except these are empirical arguments with little empirical data to make any determination, which is part of my point. Software correctness is such a complicated topic and, if anything, it's become more, not less, mysterious over the decades (see Tony Hoare's astonishment that unsound methods have proven more effective than sound methods in many regards). It's now understood to be a complicated game of confidence vs cost that depends on a great many factors. Those who claim to have definitive solutions don't know what they're talking about (or are making unfounded extrapolations).

CyberDildonics 1y ago
C++ doesn't. Then why do my data structures detect if I go out of bounds? Interestingly, almost all of Rust's complexity is invested in the less dangerous kind of memory unsafety I didn't say anything about rust. So RAII is part of the definition of memory safety now? Yes. You can clean up memory allocations automatically with destructors and have value semantics for memory that is on the heap. Why not just declare memory safety to be "whatever Rust does", say that anything that isn't exactly that is worthless, and be done with that, since that's the level of the arguments anyway. Why are you talking about rust here? Focus on what I'm saying. We could, of course, argue over which of Rust, Zig, and C++ if anything, it's become more, not less, mysterious over the decades Says who? I don't care about rust or zig, I'm saying that these are solved problems in C++ and I don't have to deal with them. Zig does not have destructors and move semantics.
- pron 1y ago
  > Then why do my data structures detect if I go out of bounds? I didn't mean you can't write C++ code that enforces that, I said C++ itself doesn't enforce it. > Yes. You can clean up memory allocations automatically with destructors and have value semantics for memory that is on the heap. Surely there are other ways to do that. E.g. Zig has defer. You can say that you may forget to write defer, which is true, but the implicitness of RAII has cause (me, at least) many problems over the years. It's a pros-and-cons thing, and Zig chooses the side of explicitness. > Why are you talking about rust here? Focus on what I'm saying. You're right, sorry :) > Says who? Says most people in the field of software correctness (and me https://pron.github.io https://pron.github.io). In the seventies, the prevalent opinion was that proofs of correctness would be the only viable approach to correctness. Since then, we've learnt two things, both of which were surprising. The first was new results in the computational complexity of model checking (not to be confused with the computational complexity of model checkers; we're talking about the intrinsic computation complexity of the model checking problem, i.e. the problem of knowing whether a program satisfies some correctness property, regardless of how we learn that). This included results (e.g. by Philippe Schnoebelen) showing that even though there would be the reasonable expectation that language abstractions could make the problem easier, even in the worst case - it doesn't. The second was that unsound techniques, including engineering best practices, have proven far more effective than was thought possible in the seventies. This came as quite a shock to formal methods people (most famously, Tony Hoare, who wrote a famous paper about it). As a result, the field of software correctness has shifted its main focus from proving program correct to finding interesting confidence/cost tradeoffs to reduce the number of bugs, realising that there's no single best path to more correctness (as far as we know today). > I'm saying that these are solved problems in C++ and I don't have to deal with them. Zig does not have destructors and move semantics. That's true, but these are not memory safety guarantees. These are mechanisms that could mitigate bugs (though perhaps cause others), and Zig has other, different mechanisms to mitigate bugs (though perhaps cause others). E.g. see how easy it is to write a type-safe printf in Zig compared to C++, or how Zig handles various numeric overflow issues compared to C++. So it's true that C++ has some features we may find helpful that Zig doesn't and vice-versa, we can't judge which of them leads to more correct programs. All I said was that Zig offers more safety guarantees than C++, which it does.