What are the lessons of Erlang Joe gives good talks. Here's one he recommends as an intro to the capabilities and philosophy of Erlang: https://www.youtube.co

What are the lessons of Erlang Joe gives good talks. Here's one he recommends as an intro to the capabilities and philosophy of Erlang: https://www.youtube.com/watch?v=u41GEwIq2mE https://www.youtube.com/watch?v=u41GEwIq2mE The entire Erlang thesis falls out of one simple fact: for a program to be highly available, it must run on more than on piece of hardware. When you run on more than one piece of hardware, you need to be able to communicate between pieces of hardware, detect failures, and when something fails you need to be able to restart it (hacks: systemd, SMF) or reassign responsibility to a different piece of hardware that hasn't failed yet. Monitoring and restarting in itself isn't simple. What if what you're monitoring is on another physical machine? You need built in networking and for simplicity, you need built in location transparency. If I start process Bob on machine A and process Kat on machine B, I should be able to interact with Bob on either machine without specifying where it's running (i.e. RMI that works). And all of this is the Erlang VM so far—nothing to do with the language itself. The language adds nice features like pattern matching and atoms and tuples and cons cells and binaries and bignums, but those features are independent of the "Erlang-ness" of the runtime. There are a lot of great articles written about rationales behind all these topics and a lot of great talks up on YouTube. Just search YouTube for Joe Armstrong talks and/or general Erlang intro talks. You'll soon see how the basics of Erlang are being re-implemented in 2015, except half thought through, and it'll take another 10 years for these ad-hoc remade components to become "I'd bet the farm on it" reliable.