In most other programming languages, software crashes have always been (and often still are) considered highly undesirable situations that must be avoided at all costs. Consequently, elaborate exception handling mechanisms exist to trap these situations and then mitigate their effects. This design philosophy exists because many of the foundational principles of software design were defined at a time when computers were single processor machines. Under these conditions, software crashes were indeed fatal. Given this basic constraint, it was perfectly natural therefore to develop programming styles in which a large proportion of the code was dedicated to detecting and then handling error situations. This in turn, led directly to the still widely popular coding style known as defensive programming.
However, the designers of Erlang realised that in spite of their undesirable effects, software crashes are much like death and taxes - quite unavoidable. Therefore, rather than treating a crash as a crisis situation that temporarily suspends all normal work until a solution is found, they reasoned it would make far greater sense to treat a crash in exactly the same manner as any other normal runtime event. Consequently, when an Erlang process crashes, this situation is reported as just another type of message arriving in a process’ mail box.
@alex
That sounds.... horrible and dangerous.
Software does not just crash. Why would they even want to treat crashes as normal?
I am not a programmer, but what do they want to achieve? If there is a crash, the program is obviously not where it should be. Why would you not stop it before 1/2 of your disk is gone or something?
Am I missing some joke? This sounds like:
one of tank shells didn't leave the barrel, just load another one and try again...
Accept the fact that bad things will happen that you didn’t foresee and let it happen in a safe environment.
Crash fast, recover fast. The alternative is “wait this wasn’t supposed to crash... how did we miss... I swear we wrote a test for that...”
Look up supervisors and umbrella applications. They’re awesome.
>Avoid pretending like you can account for every single edge case scenario that could occur.
>Accept the fact that bad things will happen that you didn’t foresee and let it happen in a safe environment.
Except, that sounds like tbe exact opposite of what is written above. The crash is a point, where even computer can clearly tell, that something is wrong, so not to kill the entire process is irresponsible at best, and suicidal at worst.
>Look up supervisors and umbrella applications. They’re awesome.
thanks, I will. I hope it won't be just some feel good esotery though... 
Processes are isolated from each other, run concurrent to one another and communicate via message passing. Processes are not only the basis for concurrency in Elixir, but they also provide the means for building distributed and fault-tolerant programs.
Elixir’s processes should not be confused with operating system processes. Processes in Elixir are extremely lightweight in terms of memory and CPU (even compared to threads as used in many other programming languages). Because of this, it is not uncommon to have tens or even hundreds of thousands of processes running simultaneously.
Just go to elixir-lang.org
@LukeAlmighty @alex to make a comparison imagine you are running a restaurant and one of your employees went to the store to get a egg but drops the egg. The classic software solution is that all other employees stop working while he runs to the store ro get another egg. And only start working again once he is back at the samle place he dropped it. While in erlang the other employees continue working while he fetches a new egg.
>That sounds.... horrible and dangerous. Software does not just crash. Why would they even want to treat crashes as normal?
Because they lost their damn mind.
@alex