I think Go has a long way to (forgive the pun) go before it can really start to compete with the entire Erlang ecosystem. Only having a modest knowledge it both, Erlang is still built around stability. Hot code patching, an extremely instrumentable VM, the whole OTP framework, simple networked Actors. Erlang was built with telecom in mind.
That's not to say they can't inhabit a lot of the same areas, but Go's area of interests will probably remain somewhat separate from Erlang.
But there are more here and there if you hunt for them.
I think for things where they are sort of similar, Go will definitely be the more successful language because it looks so much more familiar and because it's moving faster with more momentum, at this point.
I'm using Erlang for a semi-embedded thing at the moment, though, where stability is more important.
Whenever I think about Erlang's stability I recall the problems mentioned by CouchDB authors and RabbitMQ users. Apparently CouchDB hit some problems with low level disk access that they couldn't trace and that pushed them to migrate away from Erlang. RabbitMQ is allegedly dropping lots of messages for unknown reasons under heavy use. I do not have the links at hand for reference but such stories make me wonder how battle-tested Erlang really is when you need to persist your data (and not just transmit it over the network).
The Riak guys have better experience here and I would argue that it's pretty well battle-tested when Apple is deploying hundred node Riak clusters for production :) (Riak is built on-top of Erlang)
Go will not eat into Erlang. Go's type system is deplorable and an embarrassment, it lacks a virtual machine to do the things Erlang can do, it lacks all of OTP, etc...
What I do see eating into Erlang is Scala and Akka, though.
I like this blog post (http://blog.erlware.org/some-thoughts-on-go-and-erlang/) as it talks about some of the differences about them. For some of these reasons I don't think they solve the same issues and one won't eat the other.
Having used both, I don't think Go and Erlang are even close in comparison. Go's lack of go routine isolation and error handling will never allow it to properly handle the problems Erlang was designed for without a lot of defensive programming and pain. Start 20,000->30,000 go routines and have one of them crash, taking down the other 29,999 go routines and now try and debug that problem in production? Go tries to advertise that it was built writing important services in, but it's shared everything model really argues against that. Erlang's hot code loading, runtime inspection, production quality REPL, and process isolation makes it a completely different language than Go. Until Go routines and channels get way way better, I would never attempt to write a distributed server that needs high availability in Go, it is just too fragile atm.
On the other side of the coin, if I wanted to write a simple command line tool quickly that was easy to deploy to many servers, Go might be a great choice, where Erlang is a bit painful for small and simple programs.
Yeah, both Java and (currently) Scala are imperfect host languages as well. Global GC is not ideal. Everything's not golden, and it's not better than Erlang in general, but Scala+akka is really awesome for a lot of tasks. For most people looking at Erlang, Scala+akka will be more suitable, I think. Still, if I were to write something powering some really reliability-heavy stuff (like telecom stuff) I would probably go with Erlang.
Scala+akka may be easier for Java programmers looking at Erlang, and perhaps enough so to make it "more suitable" when you look at net cost/benefit. OTOH, coming from other directions -- particularly dynamic languages -- Erlang may be easier, as well as its other advantages.
For people coming from dynamic languages, especially Ruby, it's worth looking at Elixir. Elixir runs on the Beam VM (same as Erlang) and is fully Erlang compatible while fixing many of Erlang's warts, including offering a Ruby-inspired syntax and macros. Here's a fun introduction: http://howistart.org/posts/elixir/1
I agree that its worth looking at (and I need to find time to take another swing at it), but I have to admit that when I came into it from Ruby (having also had some experience with Erlang, but not need), I found the Ruby-like syntax with very different semantics an obstacle rather than a help -- it had a kind of "uncanny valley" effect.
That's been my defense of Erlang's syntax ever since I learned it. Having it be unlike anything I'd experienced before meant it was easy to learn, because I wasn't trying to shoehorn my own expectations upon it. And I'd wager it's why the if statement strikes so many people as being completely weird and 'broken' in Erlang.
It's about 10 times faster, the language has way more modern syntax and constructs. It is not constricted to the actor model only. Erlang has perfected a subset of Scala+akka at slower speed.
Loïc Hogun (author of Cowboy, other projects) said:
As Go gains libraries like groupcache will it become more and more go-to for networked and shared systems?Is Go moving up from concurrent to fault-tolerant in a real way?