[shadowmint]

I don't accept that 'effectively impossible' means 'can happen, but probably doesn't happen very often'.

Rust has many other unsafe code paths than ffi; low level optimisations, dynamic libraries, etc.

Unless you go out of your way or are doing low level work, your code will not contain such bugs, and if you used no dependencies that do anything meaningful, what you said is plausibly true.

...but what are we trying to argue here?

That you can build a contrived rust program that doesn't crash?

Or that if you build an arbitrary program in rust, using arbitrary dependencies to do meaningful work (that will invoke a c library at some point, and talk to device drivers), that it wont crash?

In my view 'effectively impossible' is faaaaaar over stepping the bounds of reality.

[kibwen]

Inveterate Rustacean here, and I agree with this. We need to carefully clarify the sort of safety that Rust provides in order to avoid misleading people.

Improperly implemented `unsafe` blocks can cause crashes. APIs that don't properly isolate unsafe interfaces can cause crashes. Bugs in the compiler, bugs in LLVM, and unforeseen unsoundness in the type system can cause crashes. So instead of saying "Rust makes crashes impossible", I'm starting to prefer "If you write only safe code, any crashes that occur are not your fault". A bit less comforting, but still a best-in-class guarantee for a bare-metal language (not to mention that the former claim is impossible in any language).

Furthermore, I think it's important to express to people the true role of `unsafe` blocks, which are not so much "Rust without safety" as they are "reified inline C code with a bit more safety". Rust without `unsafe` blocks could exist, but it would require an enormous amount of FFI and/or much more machinery baked into the compiler itself.