5 ms·
This is why Erlang's crash early and restart philosophy was so eye opening when I became more and more familiar with the language and design. The whole language
by jrobn 8y ago
This is why Erlang's crash early and restart philosophy was so eye opening when I became more and more familiar with the language and design. The whole language is about managing state and managing it well in a dynamic realtime environment (versus Rust's explicit state encoding for example).
- verdagon 8y agoCan you tell me more about Erlang's approach? Quite interested in learning of new ways to deal with state and errors.
- zzzcpan 8y agoTried to explain it here: https://news.ycombinator.com/item?id=18534441 https://news.ycombinator.com/item?id=18534441
- dnautics 8y agoIt's called the "let it crash" philosophy. The idea is that things are going to go horribly wrong no matter how well your code and everyone else's code is written. If you program for resilience, that is the ability to recover from a horribly bad event, then you can get high service availability and faster development (you're not obsessed with checking for errors, you only handle the most common ones and program to capture enough errors to achieve the service level you are comfortable with or have agreed to).
- jlouis 8y agoIsolate all memory so a failure is compartamentalized Discriminate between the error-kernel of the program and the rest. The kernel is the part which is not allowed to fail. Goal: keep it small. Discriminate between errors you have seen happen, and everything else. Handle the errors you've seen. It looks a bit like Go's handling, but only for things where you know you have an error flow. There are also exceptions, but they are somewhat rarer in typical code. On an unhandled error, crash the isolated process. This produces, a state of the memory, a stack trace and eventually the last few messages sent to that process. The system has a recovery model which will restart failed processes from a last known good state. The programming language is functional, and quite much so, so there are orders of magnitude fewer errors relating to state manipulation. One typical approach is to use the crash as a way to learn about errors that can happen, then patch those errors by handling them. Because you have a strategy for reactively handling errors, it is far less dangerous to have them in th e program, as long as they are under a noise floor.