> I never understood why you have to take Erlang-the-language to get the distributed systems platform.
That is a very good observation. And I used to have the exact same question. It took a while to realize why Erlang is they way it is, and it makes sense to me now. I don't mean the parsed syntax, see Reia and Elixir, but its main features.
You have to go back to the roots and see why was Erlang created. Its primary focus was fault tolerance and secondary was concurrency. Everything else fell out of those.
For example:
* Actor model : it provides isolation in a large system so only a single actor process crashes on failure and it can be restarted. This means no large pool of pointers, shared data, etc. It means message passing. There is an anecdote that some systems written in Erlang are sold with contract that stipulate that any downtime longer than 4 minutes / year will be billed at $10K/minute. With these kind of goal everything has to change. Segfaults are not something that can crash the system. Too expensive. Stopping the system to upgrade and get a bugfix in -- no can do, too expensive. Also concurrency fits in here. Actors work concurrently and are responsive, their are designed to have responsiveness (low latency) over raw throughput.
* Hot Code Reloading : falls out of needing to have high uptime and fault tolerance. This means system gets updated while it runs.
* Functional Syntax : functional syntax encourages creation of referentially transparent pieces of code. This helps with hot code reloading as there is less state modified in place, rather it is passed throw the function calls.
* Single Assignment : pure torture for those coming from imperative programming. But necessary if values are to be passed between processes or if the code is upgraded on the fly. You gain a large amount of safety know that the variable X you just instantiated won't change behind your back.
* Multi-node (multi process and multi machines) distribution: for real world reliability you can't just rely on one machine, you need to have hot spares for fail-over. What takes complicated messaging and sync protocols, haproxy, message queues, zookeepers and other tools comes bundled in Erlang's standard library.
http://learnyousomeerlang.com/distributed-otp-applications#a...
As a bonus, it has one of the best pattern matching syntax I have seen. Once you start using it and get the hang of it you'll miss Erlang's pattern matching in every other language you use.
There are downsides to Erlang in terms of pure numerical performance. This is the other coin of fault tolerance and latency reduction. You can't have both there are some trade-offs involved.