It's similar in effect, but Erlang's ultimate response to the errors is redundancy instead of trying to salvage whatever was left by the process that crashed. I think the transparent distribution of Erlang nodes over the network is what enables Erlang's "let it crash and forget it ever ran" approach. Joe Armstrong said that they want Erlang to handle all kinds of problems, up to and including "being hit by a lightning" - so I think hardware redundancy is the right path here.
The OS[1] I've been talking about was primarily concerned with a single-machine environment, which resulted in slightly different design.
The OS[1] I've been talking about was primarily concerned with a single-machine environment, which resulted in slightly different design.
[1] https://en.wikipedia.org/wiki/EROS_%28microkernel%29