6 ms·

> There is also the difference in their approach to safety, but that's a complicated subject that ultimately boils down to an empirical question -- which approa

> There is also the difference in their approach to safety, but that's a complicated subject that ultimately boils down to an empirical question -- which approach is safer? -- which we don't have the requisite data to answer. We do have the requisite data to answer whether preventing use-after-free is better than not preventing it. You can argue (not successfully, in my opinion) that it's not worth the loss in productivity to prevent UAF and other memory safety issues, but it's impossible to argue that not trying to prevent UAF is somehow safer.

pron 7y ago
> We do have the requisite data to answer whether preventing use-after-free is better than not preventing it. I expect Zig will prevent use-after-free. It will be sound for safe code and unsound for unsafe code (by turning this on only in debug mode for testing). > but it's impossible to argue that not trying to prevent UAF is somehow safer. First, see above. Second, it is not only possible but even reasonable to argue that not trying to completely eliminate a certain error is very much safer. The reason is that soundness has a non-trivial cost which can very often be traded for an unsound reduction in a larger class of bugs. As an example, instead of soundly eliminating bugs of kind A, reducing bugs of kinds A, B and C -- for a similar cost -- may well be safer. There has been little evidence to settle whether sound elimination of bugs results in more correctness than unsound reduction of bugs or vice-versa, and it's a subject of debate in software correctness research.
- pcwalton 7y ago
  It's not interesting to talk about a system that might or might not exist in the future. (There is a word for that—"vaporware".) The point is that Zig doesn't even try to prevent UAF now, so you can't say that it's safer than languages that do prevent the problem. > As an example, instead of soundly eliminating bugs of kind A, reducing bugs of kinds A, B and C -- for a similar cost -- may well be safer. Hasn't this essentially been what C++ has been trying for memory safety for decades, without success? The C++ approach has been "smart pointers are good enough, and they prevent several other problems too", and the experience of web browsers (among others) has pretty much definitively shown: no, they really aren't. For memory safety, I would not bet on this approach.
  - pron 7y ago
    > The point is that Zig doesn't even try to prevent UAF now I wouldn't say Zig exists at all right now, but just as it strives to one day be production-ready, it strives to prevent use-after-free. Safety is a stated goal for the language. > Hasn't this essentially been what C++ has been trying for memory safety for decades, without success? No. I'm talking about a mechanism that can detect various errors at runtime, and is turned on or off for various pieces of code and/or for all code at various stages of development. Rust, BTW, doesn't entirely guarantee memory-safety, either, when any unproven unsafe code is used, and even when it isn't (e.g., have you proven LLVM's correctness?). We always make some compromises on soundness; the question is where the sweet-spots are. Software correctness is one area where there are no easy answers and very few obvious ones.
    - pcwalton 7y ago
      > No. I'm talking about a mechanism that can detect various errors at runtime, and is turned on or off for various pieces of code and/or for all code at various stages of development What you are describing exists: ASan. We have a pretty good answer to the question "is ASan sufficient to prevent memory safety problems in practice": "no, not really". > Rust, BTW, doesn't entirely guarantee memory-safety, either, when any unproven unsafe code is used, and even when it isn't (e.g., have you proven LLVM's correctness?). We always make some compromises on soundness; the question is where the sweet-spots are. Empirically, Rust's approach has resulted in far fewer memory safety problems than previous approaches like smart pointers and ASan, with only garbage collectors (and restrictive languages with no allocation at all) having similar success in practice. Notice that the working approaches have something important in common: a strong system that, given certain assumptions, guarantees the lack of memory safety problems. Even though those assumptions are never quite satisfied in practice, empirically having those theoretical guarantees seems important. It separates systems that drastically reduce safety problems, such as Rust and GC languages, from those that do so less well, such as ASan and smart pointers. This is why I'm so skeptical of just piling on more mitigations: they're helpful, but we've been piling on mitigations for decades and UAF (for instance) is still a big a problem as ever.
- littlestymaar 7y ago
  > reducing bugs of kinds A, B and C -- for a similar cost -- may well be safer. What kind of bugs do your have in mind that Zig would prevent and Rust doesn't ? I can think about several Rust does and Zig doesn't thanks to its afine type system, but I've yet to see a safety feature benefit in Zig.
  - pron 7y ago
    Preventing bugs with soundness is not necessarily the best, and certainly not the only, way to reduce bugs. You can reduce bugs by making code easier to read (code review has been empirically shown, time and again, to be the most effective, in terms of cost/benefit, bug reduction technique), and by making code faster to write and to compile, thus leaving more time for tests and other verification techniques. If sound elimination of bugs were the best way to write programs, we'd all be writing in Isabelle, Coq or Idris, except even those of us who do -- in fact, especially those of us who do -- know that it's not the best way to write programs.
abainbridge 7y ago
> but it's impossible to argue that not trying to prevent UAF is somehow safer. It might be possible. Someone might prove that preventing UAF necessarily increases complexity somewhere else. Like one of those laws of thermodynamics, but for software.

pron 7y ago

> We do have the requisite data to answer whether preventing use-after-free is better than not preventing it. I expect Zig will prevent use-after-free. It will be sound for safe code and unsound for unsafe code (by turning this on only in debug mode for testing). > but it's impossible to argue that not trying to prevent UAF is somehow safer. First, see above. Second, it is not only possible but even reasonable to argue that not trying to completely eliminate a certain error is very much safer. The reason is that soundness has a non-trivial cost which can very often be traded for an unsound reduction in a larger class of bugs. As an example, instead of soundly eliminating bugs of kind A, reducing bugs of kinds A, B and C -- for a similar cost -- may well be safer. There has been little evidence to settle whether sound elimination of bugs results in more correctness than unsound reduction of bugs or vice-versa, and it's a subject of debate in software correctness research.

pcwalton 7y ago
It's not interesting to talk about a system that might or might not exist in the future. (There is a word for that—"vaporware".) The point is that Zig doesn't even try to prevent UAF now, so you can't say that it's safer than languages that do prevent the problem. > As an example, instead of soundly eliminating bugs of kind A, reducing bugs of kinds A, B and C -- for a similar cost -- may well be safer. Hasn't this essentially been what C++ has been trying for memory safety for decades, without success? The C++ approach has been "smart pointers are good enough, and they prevent several other problems too", and the experience of web browsers (among others) has pretty much definitively shown: no, they really aren't. For memory safety, I would not bet on this approach.
- pron 7y ago
  > The point is that Zig doesn't even try to prevent UAF now I wouldn't say Zig exists at all right now, but just as it strives to one day be production-ready, it strives to prevent use-after-free. Safety is a stated goal for the language. > Hasn't this essentially been what C++ has been trying for memory safety for decades, without success? No. I'm talking about a mechanism that can detect various errors at runtime, and is turned on or off for various pieces of code and/or for all code at various stages of development. Rust, BTW, doesn't entirely guarantee memory-safety, either, when any unproven unsafe code is used, and even when it isn't (e.g., have you proven LLVM's correctness?). We always make some compromises on soundness; the question is where the sweet-spots are. Software correctness is one area where there are no easy answers and very few obvious ones.
  - pcwalton 7y ago
    > No. I'm talking about a mechanism that can detect various errors at runtime, and is turned on or off for various pieces of code and/or for all code at various stages of development What you are describing exists: ASan. We have a pretty good answer to the question "is ASan sufficient to prevent memory safety problems in practice": "no, not really". > Rust, BTW, doesn't entirely guarantee memory-safety, either, when any unproven unsafe code is used, and even when it isn't (e.g., have you proven LLVM's correctness?). We always make some compromises on soundness; the question is where the sweet-spots are. Empirically, Rust's approach has resulted in far fewer memory safety problems than previous approaches like smart pointers and ASan, with only garbage collectors (and restrictive languages with no allocation at all) having similar success in practice. Notice that the working approaches have something important in common: a strong system that, given certain assumptions, guarantees the lack of memory safety problems. Even though those assumptions are never quite satisfied in practice, empirically having those theoretical guarantees seems important. It separates systems that drastically reduce safety problems, such as Rust and GC languages, from those that do so less well, such as ASan and smart pointers. This is why I'm so skeptical of just piling on more mitigations: they're helpful, but we've been piling on mitigations for decades and UAF (for instance) is still a big a problem as ever.
littlestymaar 7y ago
> reducing bugs of kinds A, B and C -- for a similar cost -- may well be safer. What kind of bugs do your have in mind that Zig would prevent and Rust doesn't ? I can think about several Rust does and Zig doesn't thanks to its afine type system, but I've yet to see a safety feature benefit in Zig.
- pron 7y ago
  Preventing bugs with soundness is not necessarily the best, and certainly not the only, way to reduce bugs. You can reduce bugs by making code easier to read (code review has been empirically shown, time and again, to be the most effective, in terms of cost/benefit, bug reduction technique), and by making code faster to write and to compile, thus leaving more time for tests and other verification techniques. If sound elimination of bugs were the best way to write programs, we'd all be writing in Isabelle, Coq or Idris, except even those of us who do -- in fact, especially those of us who do -- know that it's not the best way to write programs.

abainbridge 7y ago

> but it's impossible to argue that not trying to prevent UAF is somehow safer. It might be possible. Someone might prove that preventing UAF necessarily increases complexity somewhere else. Like one of those laws of thermodynamics, but for software.