Right, so you have to make a lot of decisions on what things can fail, how often they should be allowed to fail, what side effects can be tolerated with a major

Right, so you have to make a lot of decisions on what things can fail, how often they should be allowed to fail, what side effects can be tolerated with a major failure, what happens if a bad process fails when it comes back up (thus risking causing the supervisor itself to cascade restart itself), etc... These decisions are not trivial and are exacerbated because of the Actor style of flow due to the independent pieces. So from my experience you have non-BEAM languages where a single error can take down your whole application if you don't plan your failure scenarios properly, where as in BEAM languages if you don't plan your failure scenarios properly you are more likely to end up with an inconsistent system. The former isn't that bad in a lot of circumstances as you should have an external application monitoring and restarting a critical server that's no longer running (even for BEAM systems) but the latter can be very bad because it can be a silent issue. I have systems working at my job written in .net that have been running for over 6 months without a restart, even when Azure had failures and it could not talk to its command and control server for an hour and kept running perfectly fine with using a well thought out architecture and a well placed central error handler for generic errors without things cascading throughout the whole system. So resiliency has less to do with language or supervisor trees and more to do with making every step has failure scenarios thought about and planned for.