| > Come on, please tell me you don't do this in your code. I don't, but that's not to say that I think it should never be done. > Formally you are correct, but there are many things in C++ that should have better not existed. Sure, but I think it's important that one should do their best to be correct and/or precise. > Because it would lose most of the Rust properties by that time. Perhaps for specific bits of code, but that doesn't necessarily require that your entire codebase give up on safety. Part of Rust's value is in isolating unsafe stuff to specific sections of your codebase both so the rest of the code can make use of Rust's guarantees and so if/when something goes wrong it's easier to pinpoint the problem. Not to mention if you're talking about "specially designed" codebases in the kind of situation you describe you're almost certainly not in pure-C-land either (e.g., standard C doesn't have the concept of CPU registers, so if you really need to stick to what's in registers you're going to have to resort to compiler-specific extensions and/or assembly). If you're willing to allow the necessary extensions for C, it's only fair that you do the same for Rust. > 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. There's a reason no_std exists. Low-resource embedded use has been a design focus since well before Rust's 1.0, and those considerations have continued to influence its evolution since - for example, Rust's async design is the way it is specifically to ensure it is usable in limited-resource environments. > Who's gonna GC the poisoned garbage left in undefined state after the crash? Whatever supervising process/thread you write/designate, if that kind of recovery is important to you? I don't think there's anything about Rust that precludes you writing such a thing. Not to mention, must there be "poisoned garbage" in the first place? I don't think it's strictly necessary that such a thing be produced after a crash even if you ignore the fact that part of the reason unwinding exists is to clean things up even while crashing. > but from what I know it's rather in middle of "not possible" and "not viable". I'm curious how you came to that conclusion. It seems wrong both on a theoretical level (Drop/unwinding/catch_unwind should obviously suffice for at least some cases?) and on a practical level (tokio can recover from worker thread panics just fine?). |
Tokio provides crash-resistant synchronization primitives, but it cannot recover complex structures you've been handling — you either need to write panic-handlers that would revert your data to more-or-less manageable state or employ ready-made libs that do it for you. Languages designed for crashes don't require ad-hoc recovering — they just automatically clean up everything. That's what I've called "viable".
I mean you could have written crash recovery in C++, but it's just not viable because of how many things can go wrong.