Go vs. Erlang for distribution

I&#x27;ve never really understood the desire to compare Go and Erlang. They serve radically different purposes. The only thing they share are processes&#x2F;goroutines (or greenlets, green threads, fibers, whatever you want to call them). A cheap small footprint concurrency primitive.<p>Go was created to make buildng a single server (in the software not hardware sense) easier.<p>Erlang was created to create systems for managing a lot of servers with a complicated dependency hierarchy.<p>Go doesn&#x27;t have OTP and a fault tolerant runtime because Google has all that stuff at a separate layer in their datacenters and the Go engineers didn&#x27;t feel a need to solve that problem. They wanted to solve the problem of still having to build http servers in C++ for performance and all the attendant annoyances that brings.<p>If I were going to build a massive distributed system today I&#x27;d use the Erlang runtime to manage the overall system in a fault tolerant way and I&#x27;d use Go to build the components.<p>They complement themselves well but they don&#x27;t really replace each other.

Loïc Hogun (author of Cowboy, other projects) hits the nail on the head:<p><pre><code> For me Erlang is first fault tolerant, then concurrent, then functional, yet for many people it seems to be the opposite order. I personally care very little about Erlang being functional (though I do care a great deal about immutability and pattern matching being the default behavior, the rest not so much), and the concurrency is nice but only because it enables all the fault tolerance features of the language. </code></pre> I&#x27;ve yet to encounter anything as good as OTP for building fault-tolerant systems. Go is not designed for safety like Erlang&#x2F;OTP, and as far as I know there is no concept of supervision with Go routines&#x2F;channels, etc.<p>Go is no &quot;ultimate antagonist to Erlang&quot; as OP hypothesized.

Here&#x27;s another kind of interesting&#x2F;kind of flamey one:<p>Node.js vs Erlang: <a href="https://groups.google.com/forum/#!msg/erlang-programming/ufNoiKcx1N0/L9o5Wvh7Um4J" rel="nofollow">https:&#x2F;&#x2F;groups.google.com&#x2F;forum&#x2F;#!msg&#x2F;erlang-programming&#x2F;ufN...</a><p>I think the Erlang guys are not very good at marketing (in the broad sense) their system, which is a pity, because Erlang is very nice for some kinds of applications.

So, while that was... odd, there were some links buried in there that I found to be interesting reading:<p><a href="http://carlos-trigoso.com/2014/03/07/out-of-the-labyrinth-of-metaphysics-v-001/" rel="nofollow">http:&#x2F;&#x2F;carlos-trigoso.com&#x2F;2014&#x2F;03&#x2F;07&#x2F;out-of-the-labyrinth-of...</a> (Or the Abstractitude of the Hewitt Actor Model.)<p><a href="http://jlouisramblings.blogspot.se/2012/10/ramblings-on-thesis-of-bjarne-dacker.html" rel="nofollow">http:&#x2F;&#x2F;jlouisramblings.blogspot.se&#x2F;2012&#x2F;10&#x2F;ramblings-on-thes...</a> (Or a summary of the original problems Erlang was trying to address.)