There are programming languages/models/runtimes that crash and recover, there are models that gracefully degrade. Rust cannot recover. Neither can C++ in many cases e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`.

Do note that C did not have such a flaw built into language — C++ authors invented it and Rust inherited this flaw (the authors simply did not feel like it's a flaw). I mean specially designed embedded C code can survive total RAM erasure and still perform some meaningful work (with CPU registers and ROM intact). Or compare it to BEAM that can have processes crash all day long and still continue to work. "Memory safety at all cost" is not a practical requirement — it's theological.

▲ aw1621107 2 hours ago | parent | next [-]

> Rust cannot recover.

catch_unwind exists for a reason.

> e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`.

You can throw in a destructor [1]. You just need to mark that destructor noexcept(false). You do get a guaranteed std::terminate if an exception escapes a destructor while unwinding is already underway, though.

> Do note that C did not have such a flaw built into language

assert() says hi?

> I mean specially designed embedded C code can survive total RAM erasure and still perform some meaningful work (with CPU registers and ROM intact).

Why doesn't a similar argument apply to "specially designed" Rust?

> Or compare it to BEAM that can have processes crash all day long and still continue to work.

Again, nothing stops you from writing Rust that does the same.

[0]: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

[1]: https://cpp.godbolt.org/z/ao4cf3zrr

	▲	byko3y a few seconds ago \| parent [-]
		>You can throw in a destructor [1]. You just need to mark that destructor noexcept(false). You do get a guaranteed std::terminate if an exception escapes a destructor while unwinding is already underway, though. Come on, please tell me you don't do this in your code. Formally you are correct, but there are many things in C++ that should have better not existed. >Why doesn't a similar argument apply to "specially designed" Rust? Because it would lose most of the Rust properties by that time. C code with fixed memory layout, on the other hand, is ideomatic and was widely employed in the past. It's still being employed in embedded. I'm not saying that you are wrong though, there might be people optimizing Rust for this very purpose, but I'm not aware of such an effort. >catch_unwind exists for a reason. >>Or compare it to BEAM that can have processes crash all day long and still continue to work. >Again, nothing stops you from writing Rust that does the same. Who's gonna GC the poisoned garbage left in undefined state after the crash? I'm not saying it's impossible — I honestly have no idea whether safe recover is possible in Rust, but from what I know it's rather in middle of "not possible" and "not viable".

▲ EnPissant 2 hours ago | parent | prev [-]

Nothing forces you to panic in Rust any more than anything forces you to call abort() in C.

    let a = b.unwrap();

is conceptually no different to:

    if (b == NULL) {
        abort();
    }
    a = *b;

don't write either if you don't want to halt.