I tweeted this about Joe: > I wish I'd gotten to meet @joeerl. So bright and enthusiastic. Erlang embodies so many insights that seem obvious in hindsight. Eg,

I tweeted this about Joe: > I wish I'd gotten to meet @joeerl. So bright and enthusiastic. Erlang embodies so many insights that seem obvious in hindsight. Eg, you can't prevent all programmer mistakes. You can't ensure computers never die or get disconnected. All you can do is make a system that copes. > Many programming languages and tools exist to deal with the basic fact that humans make mistakes. Type checking, encapsulation, TDD, etc - all because without help, we will do dumb things. Erlang taps us on the shoulder and says "and ALSO your computer could melt. Start there." > In Joe's words, "To guard against the failure of an entire computer, we need two computers." Obvious. Brilliant. > The only place you can handle failure of a process on Machine A is in a process on Machine B, which can't share any memory with the first process and can only pass messages to/from it. And for consistency, Erlang handles all failures that way. > Then you notice that these shared-nothing processes are easy to run concurrently because neither can mutate the other's state and cause race conditions. And that this scales beautifully when you have multiple CPUs. > These are some of the insights I got from reading Joe's thesis. I'm sure I missed a lot of others and hope to re-read sometime. I wrote up some of what I learned at 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...