I think this may be over generalizing to where there’s maybe a false equivalence. If I look at throwing and/or catching exceptions in, say, Java… I’m really dealing with managing errors in logic or data: unanswered is what to do about the runtime impacts which are left to the developer to figure out (or to delegate to some external library/framework/tool). In Elixir the equivalent isn’t the supervisor, but Elixir exceptions, try, catch, rescue, etc. all of which exist without invoking supervisors and deal with that logic/data domain. The Elixir/Erlang supervisor is about dealing with the runtime consequences of error: if I fail to capture error at the logic level what happens at the runtime? Supervisors provide an answer to that question. I appreciate that I’m drawing a somewhat fine line, but I think it’s an important distinction between the BEAM and other runtime environments.
For a lot of problems, having both the logic and runtime error management questions dealt with by mature constructs built into the VM (or the standard libraries) means that I don’t have to solve those questions myself, even if that solve is just picking the right external library/framework. I expect the BEAM will beat my hare-brained ideas about fault-tolerance and recovery every day and it gives me simple rules to play by (which seems in part to be the point of Erlang if I read Joe Armstrong’s thesis correctly). Yes, having runtime error handling baked in at such a low level I expect that it’s more prescriptive than those other languages which leave it open and there are trade offs such as raw performance and such… but that’s part of of choice of whether or the BEAM is suitable or not for a project. And also yes, you can still screw up a BEAM based application and end up with a crashed application at the slightest error… but your chances of getting it in the domain of “right” are ultimately better following the more prescriptive path than not.
A long time ago I was deciding between Rust and Elixir. Rust for its overall performance and its own prescriptive aspects in dealing with memory and data (C/C++ scare me). I considered conservative choices like Java or C#, too,… but ultimately the BEAM won because I realized I didn’t need the raw performance of a Rust and it came with fairly straight forward answers to problems like concurrency and fault-tolerance which are not problems I am likely to be great at solving: I would likely end up with a more resilient, available, and concurrent system building on the BEAM than I would with anything else. Elixir was language of choice because I felt it had the right expressiveness for business systems problems.
