I love Elixir, Erlang, and BEAM, but tbh, not crashing is a fairly well solved problem in the web world regardless of language and runtime, in large part due to the request/response nature of things.
Yes, it's true, but what I mean is that in Elixir I can just write the happy path and not crash the system. My Python code requires meticulous exception handling, sometimes taking up half of some functions. It's the design of the BEAM that allows you to focus on just the happy path, and this is really where most user value is derived, and it's the most fun code to write as well.
I am not the best Python programmer! I have crashed prod before, I will admit it. And this requires an alert, scurrying to the nearest terminal, an SSH console, some log spelunking, hopefully just a restart. But I have never had this experience deploying Elixir or Phoenix, and I am by no means the best Elixir programmer. Firefighting is to me the worst part of programming, and through a combination of interactive Elixir shells, process isolation, automatic process restarts, and a philosophy of "let it fail, it's no big deal," it has brought some joy back into my work. That alone is priceless!
I understand Elixir can seem overhyped, and I share that skepticism, but I keep coming back to it over the last half decade or so. This is the best endorsement I can give, I think.
In Elixir, it's almost free to isolate the user who caused them (keyword: "almost"... there are no bulletproof solutions). In most other popular languages used for web programming, it's easy for a crash to affect many users without careful thought to prevent it.
In my experience it isn't almost free. The "problem" being the overloaded nature of processes: their sole purpose isn't to isolate errors, its also to provide concurrency, a sort of access control (since a process goes through its mailbox 1 message at a time), and you also have to consider data access performance characteristics (since sending data across processes is copied).
So in an ideal world yes, you can isolate them, but I've never really achieved this panacea in practice, and its never been anywhere near free to try to suss out a design that optimally achieves all those differing design aspects at once.
Processes are only overloaded in that they are a primitive. I'm not sure if this is what you're implying, but a single process shouldn't be doing all those jobs at once. For example only supervisors should be dealing with error isolation. As for sending large amounts of data between processes, I can only speak really generally here, but one common way is to flip the script and send functions to the data instead of the other way around but ya, bigger topic! When I say for "free" I mean more like my sibling comment where you don't have to think about every possible way something can fail.
As much as people love to hate it, PHP is also really good here. Each request is isolated.