A very nice description of Erlang/Elixir resilience. > Fundamentally, if there is nothing useful your code can do on a failure, no mitigation, no meaningful fa

A very nice description of Erlang/Elixir resilience. > Fundamentally, if there is nothing useful your code can do on a failure, no mitigation, no meaningful fallback, then you might as well have it blow up and rely on the underlying tree to make whatever is most useful out of it. I would add this is possible only because process heaps are isolated. Other systems with traditional threads/co-routines/green threads can mimic supervision trees, but unless they have isolated heaps and can safely crash at any time never affecting any other processes, it would be hard to achieve the same safety properties. > Scheduling and preempting was intended to produce consistently low latencies but it also protects you from heavy workloads bogging things down, it prevents infinitely looping bugs from slowing the system to a crawl and in general makes things resilient to things not being ideal all the time. Well put. Reliability was one of the initial requirements of Erlang, but soft real-time properties was another one. This is hard to do, but BEAM VM does a great job there. To get this right the VM has to be able to preempt processes, even if they run a tight CPU bound loop. A misbehaving process may not just crash, it could just endlessly recurse, burning CPU cycles, but still shouldn't bring the system down. > The strategies are normally one_for_one, one_for_all and one_for_rest Minor correction, the last one is rest_for_one https://www.erlang.org/doc/man/supervisor.html#supervision-principles https://www.erlang.org/doc/man/supervisor.html#supervision-p...