Actor model libraries exist in various states of maturity for Go, as well.
Erlang uses the actor model, while Go uses (a modified version of) CSP. Earlier versions of CSP were more like the actor model in that they did not introduce a level of indirection (the channel). But it's not the same concurrency model.
You appear to be interpreting "some attributes" as a deep-dive analysis into the unique traits of what makes Erlang,
What else am I supposed to do? Otherwise, it would be a statement as meaningless as 'Haskell shares some properties with Algol 68'. I am pretty sure it does.
That was never the intention, and I'm not sure what motivated this.
Erlang is well-known for its concurrency features and the reliability provided by the actor model (including supervision, etc.) (e.g. in telephone systems). It is quite easy to read the quoted sentence as an attempt to give a good reputation to Go by comparing it to Erlang. I only question if such a comparison is warranted.
Actor model libraries exist in various states of maturity for Go, as well.
Well, if they are available in various states of maturity, I am interested to know which one is the most mature. Does it cover most of the functionality of Erlang and Akka?
(The most interesting package that I found some time ago was a binding against the Erlang C nodes functionality.)
That's a lot of handwaving. The overlap is that both Go and Erlang have lightweight threads. But Erlang uses the (fairly) different actor model, which usages messaging between actors, supervision trees to control and monitor the life cycles of actors, remote actors, etc. Go has lightweight threads and channels to communicate between threads. Go (concurrency) shares very little with Erlang.
It's also funny that they move on to claim that Go has better concurrency support than Java, when in fact, you can use real Erlang-like actor networks in Java by adding one dependency to your Maven file. Akka actors are lightweight concurrent entities, since you can easily create hundreds of thousands or even millions of actors.
That said, it's interesting to see one API for multiple clouds.
[1] http://akka.io/