Personally, for me it was the other way around. Discovering Erlang (and Elixir) removed all uses of Go that I had. I primarily used Go for writing networked applications. I never needed crazy CPU throughput on a single point of execution. Erlang's way of modeling concurrency and the built-in facilities of OTP made me way more productive than re-inventing the wheel via channels.
Nah, Golang is wonderful and I use it for a lot of stuff, but it's sort of a different thing than Erlang.
Go is more of a systems-ish language that has an emphasis on concurrency, but also on being relatively C-like. It's much more general-purpose than Erlang.
Erlang is more about fault-tolerant, concurrent applications, and more specifically servers. It's not designed to be especially fast, it's designed to make it very simple to write systems with a ton of throughput, that can handle outages, and perform passably in the process.
They're different things, and the only thing they have in common is that they both advertise concurrency, really.
I was wondering this when Go came out. But time has shown they solve problems very differently, so they are not really direct competitors.
Erlangs primary difference over Go is that it can gracefully handle the case where a programmer has made an error in the program by accident. A typical Go program cannot gracefully recover from an error which were unforseen and never considered by the programmer. The Erlang equivalent Erlang program, however, has mechanisms to safely clean up resources for the faulty part and then get on solving work. This is the reason Erlang has a nice robustness story.
Supervisors for golang. It looks excellent. I personally have fallen for Elixir and think the syntax, immutability, community and class functionality like Phoenix.Presence make me bet that it'll be bigger than Python for jobs in 5 years.
The main thing Go and Erlang share is their approach to concurrency: write synchronous code using lightweight processes, instead of writing asynchronous code with callbacks/promises/futures/etc. The main difference is the the fault tolerance Erlang brings (thanks to immutability and absence of memory sharing).
This is certainly something useful for Go, but it's only one aspect of Erlang.
You still don't have to guarantee of thread-safety, you still don't have the immutability, you still don't have tail-call optimization, and perhaps most importantly, you don't have a REPL for hot-code updates.