3 ms·
Nice points I suppose the core issue is transactions. Erlang could still fail with them ! {sub, n} crash() me ! {add, n} But typically Erlang's isolate
by tsegratis 4y ago
Nice points
I suppose the core issue is transactions. Erlang could still fail with
them ! {sub, n}
crash()
me ! {add, n}
But typically Erlang's isolated processes means many transactions can fail or rollback in isolation
I suppose instead transactions could be a core language semantic. But hard to do, and erlang actors gives a lot, for very little overhead
- jerf 4y agoErlang qua Erlang doesn't have any transactions, either, so Erlang qua Erlang can't fail that way. In general, whatever it was the crashing process was doing can still have failed. This obviously doesn't magically fix database transactions, or make it so files are never half written because it crashed in the meantime, or any other "external" action that you can still have failed to protect properly from crashes. It only means that the runtime can't get stuck due to locks failing to be released. But hey, that's something!