[jerf]

In addition to the other fine replies, it helps to remember that Erlang/BEAM, and by extension Elixir, comes from the telephony world. If something crashes in that world, you'd far rather terminate a phone call spuriously than bring the whole system down. (And in the 1990s, when the main alternative was C, and not just C as it may be today but 1990s C specifically, that was a reasonable concern.) Erlang is optimized for a world where that's a reasonable response to a failure. I've also used it in a context where a system makes a persistent connection up to a controller, and if either side crashes they automatically reconnect. "Let it crash" is a reasonable response to a lot of issues that can arise.

The farther you get from that being an issue, the less useful the "let it crash" philosophy becomes, e.g., if I hit "bold" in my word processor and it fails for some reason, "let it crash" is probably not going to be all that helpful overall.

I have seen systems that "should" have been failures in the field be held together by Erlang's restart methodology. We still had to fix the bugs, but it bought us time to do it and prevented the bad deployments from being immediate problems. But it doesn't apply to everything equally by any means.

[ryanjshaw]

Okay but “static typing avoids the crash to begin with”, is what everybody from the static typing world is thinking reading all these very long responses that don’t address this very basic idea.

[jerf]

I like to measure languages by "what do I miss when I leave them".

I used Erlang professionally for about 5-6 years.

I have not missed "let it crash".

It's an interesting idea that should be grappled with, but Erlang users have this tendency to very badly strawman their opposition and spout their propaganda like it's still 2005 and the rest of the world has just been twiddling their thumbs, gormlessly ramming into brick walls as they scale up and are just flabbergasted about how to handle the problems of scale, when in fact, to a first approximation all of the large systems in the world that are reliable are also not written in BEAM. There are other solutions to the problem. Strong types are a big component of how I deal with this in my current code, yes. It's not 100% a solution, but then, I can have both anyhow so I generally do.

I was just providing context. When trying to understand BEAM it is always helpful to have in the back of your head that it was written for telephony, with all that implies.

[ryanjshaw]

Apologies, I should’ve directed my reply to somebody else - your take was well balanced.