3 ms·

Rust has a particular definition of unsafe that they've documented here: https://doc.rust-lang.org/nomicon/what-unsafe-does.html https://doc.rust-lang.org/nomic

Rust has a particular definition of unsafe that they've documented here: https://doc.rust-lang.org/nomicon/what-unsafe-does.html https://doc.rust-lang.org/nomicon/what-unsafe-does.html They have also documented some frequently discussed behavior that is not considered unsafe here: https://doc.rust-lang.org/reference/behavior-not-considered-unsafe.html https://doc.rust-lang.org/reference/behavior-not-considered-... For each of the items on the second list, I believe there are languages that would consider those behaviors "unsafe", but rust doesn't - ultimately it's an arbitrary choice. So, it's important to be clear about what model of "unsafety" we're talking about.

chubot 3y ago
Yes definitely, which is why I mentioned Cardelli. Previous comment on the same subject: https://news.ycombinator.com/item?id=21832009 https://news.ycombinator.com/item?id=21832009 A program fragment is safe if it does not cause untrapped errors to occur. Languages where all program fragments are safe are called safe languages. Therefore, safe languages rule out the most insidious form of execution errors: the ones that may go unnoticed. -- Luca Cardelli It's certainly fine for Rust to have a keyword called "unsafe". But as you note, users should remember that this isn't equivalent to semantic safety. --- As a trivial example, integer overflow IS unsafe in Rust, but it's allowed WITHOUT using the unsafe keyword. Any language that traps integer overflow, regardless of debug/release mode is safer than Rust in that respect. Python is also safer than Rust in that respect, because it allows arbitrary sized integers. Rust made a tradeoff for efficiency, which is appropriate for its use cases, just like C did at the time. --- Programmers often use/abuse terms from computer science, which is perhaps OK when the difference doesn't have engineering consequences. Here it absolutely has consequences -- a crash is SAFE because it protects you from undefined behavior at runtime. Crashes are also easy to debug. I think the fallacy is that there's any other option. Many errors can't be caught at compile time, because they're simply incomputable problems. The mathematically BEST behavior is to crash. Related thread: https://old.reddit.com/r/ProgrammingLanguages/comments/tqtxfx/abstraction_not_what_you_think_it_is/i2kw2vc/ https://old.reddit.com/r/ProgrammingLanguages/comments/tqtxf... e.g. "Regular expression" was abused by programmers, and that one also has significant engineering consequences. O(n) time and O(1) space are desirable engineering properties. So if people let one definition of "unsafe" take over, then they've lost the ability to think clearly about the problem. There are languages that are safer than Rust now (e.g. Python), and there will likely be languages in the future that are both safer and more efficient. (Maybe Mojo if they do something different WRT bounds checking).
- tialaramex 3y ago
  > As a trivial example, integer overflow IS unsafe in Rust, but it's allowed WITHOUT using the unsafe keyword. To reach this conclusion you need to decide that even though the behaviour (in compiler modes which don't panic on overflow you get wrapping) is well-defined it's somehow an "untrapped error" which sounds a great deal like nonsense to me. Maybe you've been talking too much to the gentlemen Babbage complained about, "if you put into the machine wrong figures, will the right answers come out?" If you can afford to do overflow checking in production and would rather panic, today your two options are: checked arithmetic (e.g. 127i8.checked_add(127i8).unwrap() will panic) or to switch on the overflow checks even in optimised builds. Some day, perhaps a Checked<T> will join Wrapping<T> and Saturating<T> so that you can explicitly express this in the type itself. I actually find Wrapping<u8> is rather pleasant to work with, having the same properties as unsigned char in C but with the overflow behaviour more explicit as part of the type. As to what can't be done. You're think about General Purpose languages, but there's no good reason that so much of our software should be written in a General Purpose language. When the language can't express "Email the new model schematics and 2024 financials to our competitors in China" even if that was specifically what you wanted to do, good luck to hackers trying to make your program do that when it wasn't supposed to. This is the rationale for languages like WUFFS. WUFFS doesn't have integer overflows, they don't compile. That is what safer than Rust looks like, not Python.

chubot 3y ago

Yes definitely, which is why I mentioned Cardelli. Previous comment on the same subject: https://news.ycombinator.com/item?id=21832009 https://news.ycombinator.com/item?id=21832009 A program fragment is safe if it does not cause untrapped errors to occur. Languages where all program fragments are safe are called safe languages. Therefore, safe languages rule out the most insidious form of execution errors: the ones that may go unnoticed. -- Luca Cardelli It's certainly fine for Rust to have a keyword called "unsafe". But as you note, users should remember that this isn't equivalent to semantic safety. --- As a trivial example, integer overflow IS unsafe in Rust, but it's allowed WITHOUT using the unsafe keyword. Any language that traps integer overflow, regardless of debug/release mode is safer than Rust in that respect. Python is also safer than Rust in that respect, because it allows arbitrary sized integers. Rust made a tradeoff for efficiency, which is appropriate for its use cases, just like C did at the time. --- Programmers often use/abuse terms from computer science, which is perhaps OK when the difference doesn't have engineering consequences. Here it absolutely has consequences -- a crash is SAFE because it protects you from undefined behavior at runtime. Crashes are also easy to debug. I think the fallacy is that there's any other option. Many errors can't be caught at compile time, because they're simply incomputable problems. The mathematically BEST behavior is to crash. Related thread: https://old.reddit.com/r/ProgrammingLanguages/comments/tqtxfx/abstraction_not_what_you_think_it_is/i2kw2vc/ https://old.reddit.com/r/ProgrammingLanguages/comments/tqtxf... e.g. "Regular expression" was abused by programmers, and that one also has significant engineering consequences. O(n) time and O(1) space are desirable engineering properties. So if people let one definition of "unsafe" take over, then they've lost the ability to think clearly about the problem. There are languages that are safer than Rust now (e.g. Python), and there will likely be languages in the future that are both safer and more efficient. (Maybe Mojo if they do something different WRT bounds checking).

tialaramex 3y ago
> As a trivial example, integer overflow IS unsafe in Rust, but it's allowed WITHOUT using the unsafe keyword. To reach this conclusion you need to decide that even though the behaviour (in compiler modes which don't panic on overflow you get wrapping) is well-defined it's somehow an "untrapped error" which sounds a great deal like nonsense to me. Maybe you've been talking too much to the gentlemen Babbage complained about, "if you put into the machine wrong figures, will the right answers come out?" If you can afford to do overflow checking in production and would rather panic, today your two options are: checked arithmetic (e.g. 127i8.checked_add(127i8).unwrap() will panic) or to switch on the overflow checks even in optimised builds. Some day, perhaps a Checked<T> will join Wrapping<T> and Saturating<T> so that you can explicitly express this in the type itself. I actually find Wrapping<u8> is rather pleasant to work with, having the same properties as unsigned char in C but with the overflow behaviour more explicit as part of the type. As to what can't be done. You're think about General Purpose languages, but there's no good reason that so much of our software should be written in a General Purpose language. When the language can't express "Email the new model schematics and 2024 financials to our competitors in China" even if that was specifically what you wanted to do, good luck to hackers trying to make your program do that when it wasn't supposed to. This is the rationale for languages like WUFFS. WUFFS doesn't have integer overflows, they don't compile. That is what safer than Rust looks like, not Python.