If you're running a web server running the Phoenix framework on Elixir, and you're processing a request and an (unhandled) error is raised, the request fails wi

If you're running a web server running the Phoenix framework on Elixir, and you're processing a request and an (unhandled) error is raised, the request fails with a 500 and the rest of the web server runs fine, other requests process normally, the whole elixir/erlang/server process keeps running. The "let it crash" is referring more towards letting the specific operation you're operating under (i.e. a single web request, a scheduled job, an async method, etc.) crash, and let the thing supervising it handle the restarting of it. Processing a request and running in to a "let it crash" scenario doesn't mean bringing the whole thing down, it means the individual request crashes, the web server supervising it catches the crash, sets the connection to have a 500 status and returns, and life goes on as normal, the rest of the process being unaffected. In other similar scenarios the supervisor may want to restart the process after it crashes, or do something else in response. In general the ethos of erlang(/elixir) is to let things crash but more importantly have the process supervising it expect things to crash and know what to do next to recover from the crash. It may not be a novel idea nowadays (especially with web servers where presumably every implementation among every language will catch exceptions and send a 500 error), but it was a design principle when Erlang was being made, and it's baked in to the language and runtime in a fundamental first-class way where every Erlang/Elixir application you run is a supervised tree of processes that care about what to do when a process under it crashes.