> Mainly because if an application were coded in a way where it's crashing chances are it's never going to get itself back into a working state. "Let it crash"

> Mainly because if an application were coded in a way where it's crashing chances are it's never going to get itself back into a working state. "Let it crash" is not about syntax errors, it's about unexpected (ie, exceptional) errors, often as the result of a user taking a completely unexpected path in a large system that was never thought of by programmers (it's probably about more than that but I'm a BEAM n00b). It's happened plenty in web dev for me where a production worker crashes and it simply requires a restart or to be reset back to a known state because the user did something unexpected. As for tuple return in Elixir, that is simply doing it wrong if it is being used for defensive programming (and the antithesis of "let it crash"). It's meant for handling known errors and makes for a concise way of dealing with with it in the functional world—it's similar to Go's multiple returns. e.g. compared to OO (they are both pretty clean by me) # rails foo.update(params) if foo.save do_something else handle_error(foo) end # elixir case Repo.update(foo, foo_args) do {:ok, updated_foo} -> do_something(updated_foo) {:error, error} -> handle_error(error) end It's otherwise very common for an elixir function to return a bare value if it's expected to always work (and "let it crash" if it doesn't).