> There are probably many scenarios where the whole OTP philosophy of crash recovery is definitely going to help with the robustness of the platform The fundam

> There are probably many scenarios where the whole OTP philosophy of crash recovery is definitely going to help with the robustness of the platform The fundamental error that only "let it crash" can handle is hardware failure. No amount of type checking or exception catching will help if the server melts in a fire. In that case, the only solution is for a different process on a different machine to deal with the failure. This will be true for any programming stack. Erlang's approach is, since we have to delegate to a different process to handle errors in the most extreme case, let's use that approach to handle all errors, so we only have one mental model for error handling and don't have to do a lot of extra work to handle hardware failure. (Joe Armstrong refers to "errors" as times when the programmer doesn't know what to do, as opposed to exceptions, which can be rescued.) The performance story is similar: no matter your language, if you want to scale, eventually you'll need multiple processes on different machines with no shared memory passing messages to each other. For consistency, Erlang uses that model all the time. Erlang's fault tolerance decisions are what lead to its fairly good, and especially consistent, performance characteristics. I've written more about this on the DockYard blog: https://dockyard.com/blog/2018/07/18/all-for-reliability-reflections-on-the-erlang-thesis https://dockyard.com/blog/2018/07/18/all-for-reliability-ref...