> 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".
Maybe I'm a bit confused, or I haven't made my point clear enough. I'm not trying to say that Rust will clean up errors in the same way languages like Erlang do. I'm saying that you can write Rust that will clean up errors in the same way languages like Erlang do. In short, what I'm protesting is the absoluteness of the claims.
That being said, I also feel like you're comparing apples and oranges to some extent here. I don't think the more complex recovery you're describing in the Tokio example is the same thing as the cleanup you describe "languages designed for crashes" as implementing. I think the cleanup you describe "languages designed for crashes" as implementing is "weaker" (in a CS theoretical sense) than the more complex manual recovery you describe as being required when using Tokio, which means you still need to write said more complex manual recovery even in languages like Erlang.
For example, consider this email from Joe Armstrong [0]:
> In C etc. you have to write *something* if you detect an error - in Erlang it's easy - don't even bother to write code that checks for errors - "just let it crash".
> Then write a *independent* process that observes the crashes (a linked process) - the independent process should try to correct the error, if it can't correct the error it should crash (same principle) - each monitor should try a simpler error recovery strategy - until finally the error is fixed (this is the principle behind the error
recovery tree behaviour).
At least from how I read this, there's no fully "automatic[] clean up"; you still need to write the moral equivalent of "panic-handlers that would revert your data to more-or-less manageable state or employ ready-made libs that do it for you". Erlang/BEAM/etc. is not going to automatically correct errors for you in all possible cases - if it were, there would be no need to write that yourself - so I don't think it's reasonable to expect that from Rust either.
In addition, nothing here jumps out to me as being impossible to implement in Rust. Use nested threads, use catch_unwind to stop unwinding from killing the entire process, write appropriate panic handlers, etc. and you should get a similar result.
Maybe I'm a bit confused, or I haven't made my point clear enough. I'm not trying to say that Rust will clean up errors in the same way languages like Erlang do. I'm saying that you can write Rust that will clean up errors in the same way languages like Erlang do. In short, what I'm protesting is the absoluteness of the claims.
That being said, I also feel like you're comparing apples and oranges to some extent here. I don't think the more complex recovery you're describing in the Tokio example is the same thing as the cleanup you describe "languages designed for crashes" as implementing. I think the cleanup you describe "languages designed for crashes" as implementing is "weaker" (in a CS theoretical sense) than the more complex manual recovery you describe as being required when using Tokio, which means you still need to write said more complex manual recovery even in languages like Erlang.
For example, consider this email from Joe Armstrong [0]:
> In C etc. you have to write *something* if you detect an error - in Erlang it's easy - don't even bother to write code that checks for errors - "just let it crash".
> Then write a *independent* process that observes the crashes (a linked process) - the independent process should try to correct the error, if it can't correct the error it should crash (same principle) - each monitor should try a simpler error recovery strategy - until finally the error is fixed (this is the principle behind the error recovery tree behaviour).
At least from how I read this, there's no fully "automatic[] clean up"; you still need to write the moral equivalent of "panic-handlers that would revert your data to more-or-less manageable state or employ ready-made libs that do it for you". Erlang/BEAM/etc. is not going to automatically correct errors for you in all possible cases - if it were, there would be no need to write that yourself - so I don't think it's reasonable to expect that from Rust either.
In addition, nothing here jumps out to me as being impossible to implement in Rust. Use nested threads, use catch_unwind to stop unwinding from killing the entire process, write appropriate panic handlers, etc. and you should get a similar result.
Perhaps you had a different example in mind?
[0]: https://erlang.org/pipermail/erlang-questions/2003-March/007...