6 ms·

Of course not.

by charlotte-fyi 2y ago

Of course not.

OutOfHere 2y ago
Why not though (for safety-critical code)? How can it be safe with `unsafe`?
- DrMeepster 2y ago
  Unsafe is one of the most important things in rust. The point is that you stick all the unsafety into well marked areas that can be more easily checked.
  - OutOfHere 2y ago
    Pardon me as an outsider, but somehow it is not fully satisfying if the compiler cannot check it for safety.
- ogoffart 2y ago
  Unsafe is still needed in some cases to access low-level APIs or to talk to the hardware. It can still be safe because that is limited in scope, and still makes the whole product easier to review.
  - OutOfHere 2y ago
    Pardon me as an outsider, but the primary selling point of Rust is exhaustive automated compile-time safety checking. If this promise is false, then Rust needs more work.
    - steveklabnik 2y ago
      You’re asking for something that is literally impossible.
      - OutOfHere 2y ago
        Before Rust, in the early age of C, even Rust would've have been considered impossible. But is it really mathematically impossible? Even if it were, surely some bounds can be placed in the code on the damage that unsafe Rust can cause, but do such bounds exist? Even Zig has features to control the damage.
        steveklabnik 2y ago
        Every programming language has parts like Rust’s unsafe. In managed languages, that code is contained in the runtime, or in FFI. In a practical sense, in order to not have “unsafe” code, the language specification would have to contain a full formal specification of every aspect that it’s running on. The hardware, the system software you rely on, everything. That isn’t a good idea, so no language does it. And it doesn’t help you when new hardware comes out. In a more formal sense, you run into things like Rice’s theorem.
        OutOfHere 2y ago
        > Every programming language has parts like Rust’s unsafe. This is a pretty weak argument. "Everyone else does it, so it's not wrong." If using this argument, Rust shouldn't even exist. Rice's theorem seems handwavy in the real-world limitations of its restrictions. For the sake of argument, even Python is more memory-safe than unsafe Rust.
        whytevuhuni 2y ago
        Most usages of `unsafe` are necessary because of FFI calls into code written in C, into syscalls, into hardware memory-mapped regions, or other things outside of Rust's control. Without this ability, Rust wouldn't be able to call itself a systems language. There are also some usages of `unsafe` for constructs (like linked lists) that the borrow-checker does not support. Those could theoretically be checked, but as far as I know a practical/pragmatic way of doing that has yet to be invented.
- dimava 2y ago
  The things you may only fo in "unsafe" code are: - Dereference a raw pointer - Call an extern or unsafe function or method - Access or modify a mutable static variable - Implement an unsafe trait - Access fields of C unions https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html In C the most basic advanced thing you do is LinkedList. In Rust implementing it with pointers is unsafe and splitting it into two parts is unsafe
- steveklabnik 2y ago
  Safety critical projects use a variety of techniques to ensure that things don’t go wrong, and if they do go wrong anyway, that the root cause can be traced so that it will not happen again. Most safety critical projects today are written in C and C++, which have very little compile time checks for safety.
  - OutOfHere 2y ago
    > Most safety critical projects today are written in C and C++, which have very little compile time checks for safety. I find this debatable. Even if it were still true, such "whataboutism" is always a piss poor argument.
    - steveklabnik 2y ago
      What specifically about it is debatable? That most projects in these industries are in C and C++? What do you think they use instead? Or that C and C++ include very little compile time safety checks? I could see one arguing with the specific phrasing around C++, and maybe giving it a bit more credit here, but it’s still objectively less than Rust has.
      - OutOfHere 2y ago
        The part that is debatable is the tenuous definition of "today". Are you referring to new projects or to existing projects?
        steveklabnik 2y ago
        I am referring to the software currently written and deployed in things like cars, airplanes, spacecraft, medical devices, and the like. Stuff that gets certified by processes like ISO 26262 and DO-178C. Ada is of course used here too, but we're talking about the lack of checks at the language level being a problem. My point is that it is not, with languages that have less checking than Rust being used for these sorts of things routinely.

Of course not.

OutOfHere 2y ago

Why not though (for safety-critical code)? How can it be safe with `unsafe`?

DrMeepster 2y ago
Unsafe is one of the most important things in rust. The point is that you stick all the unsafety into well marked areas that can be more easily checked.
- OutOfHere 2y ago
  Pardon me as an outsider, but somehow it is not fully satisfying if the compiler cannot check it for safety.
ogoffart 2y ago
Unsafe is still needed in some cases to access low-level APIs or to talk to the hardware. It can still be safe because that is limited in scope, and still makes the whole product easier to review.
- OutOfHere 2y ago
  Pardon me as an outsider, but the primary selling point of Rust is exhaustive automated compile-time safety checking. If this promise is false, then Rust needs more work.
  - steveklabnik 2y ago
    You’re asking for something that is literally impossible.
    - OutOfHere 2y ago
      Before Rust, in the early age of C, even Rust would've have been considered impossible. But is it really mathematically impossible? Even if it were, surely some bounds can be placed in the code on the damage that unsafe Rust can cause, but do such bounds exist? Even Zig has features to control the damage.
      - steveklabnik 2y ago
        Every programming language has parts like Rust’s unsafe. In managed languages, that code is contained in the runtime, or in FFI. In a practical sense, in order to not have “unsafe” code, the language specification would have to contain a full formal specification of every aspect that it’s running on. The hardware, the system software you rely on, everything. That isn’t a good idea, so no language does it. And it doesn’t help you when new hardware comes out. In a more formal sense, you run into things like Rice’s theorem.
        OutOfHere 2y ago
        > Every programming language has parts like Rust’s unsafe. This is a pretty weak argument. "Everyone else does it, so it's not wrong." If using this argument, Rust shouldn't even exist. Rice's theorem seems handwavy in the real-world limitations of its restrictions. For the sake of argument, even Python is more memory-safe than unsafe Rust.
      - whytevuhuni 2y ago
        Most usages of `unsafe` are necessary because of FFI calls into code written in C, into syscalls, into hardware memory-mapped regions, or other things outside of Rust's control. Without this ability, Rust wouldn't be able to call itself a systems language. There are also some usages of `unsafe` for constructs (like linked lists) that the borrow-checker does not support. Those could theoretically be checked, but as far as I know a practical/pragmatic way of doing that has yet to be invented.
dimava 2y ago
The things you may only fo in "unsafe" code are: - Dereference a raw pointer - Call an extern or unsafe function or method - Access or modify a mutable static variable - Implement an unsafe trait - Access fields of C unions https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html In C the most basic advanced thing you do is LinkedList. In Rust implementing it with pointers is unsafe and splitting it into two parts is unsafe
steveklabnik 2y ago
Safety critical projects use a variety of techniques to ensure that things don’t go wrong, and if they do go wrong anyway, that the root cause can be traced so that it will not happen again. Most safety critical projects today are written in C and C++, which have very little compile time checks for safety.
- OutOfHere 2y ago
  > Most safety critical projects today are written in C and C++, which have very little compile time checks for safety. I find this debatable. Even if it were still true, such "whataboutism" is always a piss poor argument.
  - steveklabnik 2y ago
    What specifically about it is debatable? That most projects in these industries are in C and C++? What do you think they use instead? Or that C and C++ include very little compile time safety checks? I could see one arguing with the specific phrasing around C++, and maybe giving it a bit more credit here, but it’s still objectively less than Rust has.
    - OutOfHere 2y ago
      The part that is debatable is the tenuous definition of "today". Are you referring to new projects or to existing projects?
      - steveklabnik 2y ago
        I am referring to the software currently written and deployed in things like cars, airplanes, spacecraft, medical devices, and the like. Stuff that gets certified by processes like ISO 26262 and DO-178C. Ada is of course used here too, but we're talking about the lack of checks at the language level being a problem. My point is that it is not, with languages that have less checking than Rust being used for these sorts of things routinely.