>>882923
> you want hot code reload and distribution
In addition to those, one thing that makes Erlang really resilient is supervision trees.
In fact they are so good at handling errors that best practices of Erlang programming tell you to 'let it crash' instead of trying to handle all the edge cases. Basic idea is that it is better to restart from the clean state than to try to reason about all the things that you need to do to recover from every possible error condition.
It works like this, you have tree of processes/actors and if process crashes you restart it, if it crashes too many times during some period of time you restart it's parent process (and whole subtree under it) and if that parent process is restarted too many times during some period of time then you restart it's parent and so on. If root node crashes then whole program crashes. Programmer is one who chooses acceptable number of crashes and over which period are allowed for his code. I have not seen any non-BEAM (Erlang Virtual Machine) language that has anything like supervision trees.
Another thing that makes Erlang safe is share nothing concurrency, but it is double edged sword. It prevents all errors that data races cause, but it copies data a lot.
Last thing that makes Erlang so safe is that messages sent to process are processed serially, on first come first served basis, one at the time. This makes it really easy to write actors because you do not have to worry about all the pitfalls of parallel execution.
Those things make Erlang 'write once, run forever' programming language.
tl:dr; Erlang focuses on safety more than anything else, so you get program that virtually never crashes but does not perform well at calculating stuff.