4 ms·

I don't think we can go beyond the 'human limitations' if you will, of any software. Bugs happen, they're bound to. Its more, what is enforcing the Rust langua

I don't think we can go beyond the 'human limitations' if you will, of any software. Bugs happen, they're bound to. Its more, what is enforcing the Rust language guarantees and how do we know its enforcing them with reasonably high accuracy one can ascertain? I feel that it can only happen as Rust itself becomes (or perhaps it meaningfully already is) written in pure 100% safe Rust itself. At which point, I believe the matter will be largely settled. Until then, I don't think its unreasonable for someone to ask about how it verifies its assertions is all.

steveklabnik 2y ago
There is no possible way for something to be written in 100% memory safe code, no matter what the language, if you include "no unsafe code anywhere in the call stack." Interacting with the hardware is not memory safe. Any useful program must on some level involve unsafety. This is true for every programming language.
- no_wizard 2y ago
  I wasn't asking for 100%, I am asking for a reasonable proof of assertions.
  - steveklabnik 2y ago
    You may like my next blog post.
    - no_wizard 2y ago
      I think whenever someone takes the time to walk their audience through the nuances of this question its a big win. No different than how I asked of the Go community how it could produce binaries on any platform for all major platforms it supports (IE, you don't have to compile your Go code on Linux for it to work on Linux, only have to set a flag, with the exception If I recall correctly of CGO dependencies but thats a wild horse anyway)
      - rc00 2y ago
        Cross-compilation with Cgo can be resolved using something like Zig as the compilation toolchain: https://zig.news/kristoff/building-sqlite-with-cgo-for-every-os-4cic https://zig.news/kristoff/building-sqlite-with-cgo-for-every...
School-Cotton 2y ago
Yes, the rust compiler, like all complex software, has bugs. And yes, those bugs could result in memory unsafety, undefined behavior, etc. The same is true of every programming language. There might be bugs in clang or gcc so how can we prove that they actually follow the C++ spec? We can’t. rustc is no different, but nobody ever claimed it was, so why hold it to a higher standard than clang?

steveklabnik 2y ago

There is no possible way for something to be written in 100% memory safe code, no matter what the language, if you include "no unsafe code anywhere in the call stack." Interacting with the hardware is not memory safe. Any useful program must on some level involve unsafety. This is true for every programming language.

no_wizard 2y ago
I wasn't asking for 100%, I am asking for a reasonable proof of assertions.
- steveklabnik 2y ago
  You may like my next blog post.
  - no_wizard 2y ago
    I think whenever someone takes the time to walk their audience through the nuances of this question its a big win. No different than how I asked of the Go community how it could produce binaries on any platform for all major platforms it supports (IE, you don't have to compile your Go code on Linux for it to work on Linux, only have to set a flag, with the exception If I recall correctly of CGO dependencies but thats a wild horse anyway)
    - rc00 2y ago
      Cross-compilation with Cgo can be resolved using something like Zig as the compilation toolchain: https://zig.news/kristoff/building-sqlite-with-cgo-for-every-os-4cic https://zig.news/kristoff/building-sqlite-with-cgo-for-every...

School-Cotton 2y ago

Yes, the rust compiler, like all complex software, has bugs. And yes, those bugs could result in memory unsafety, undefined behavior, etc. The same is true of every programming language. There might be bugs in clang or gcc so how can we prove that they actually follow the C++ spec? We can’t. rustc is no different, but nobody ever claimed it was, so why hold it to a higher standard than clang?