"explain why they are better than Erlang or Akka's actors, STM in Clojure or Haskell,"
They aren't. I analyzed Go for my personal use, and I have a high degree of familiarity with Erlang and Haskell. The conclusion I came to was that it is a step back from Erlang and Haskell's concurrency support, and that I didn't care to step back into those problems. It's easier to do concurrency correctly in Go than it is in Python or C, but it's still pretty easy to make it blow up in your face and take down your whole program. You to both learn Go, and then learn all the implicit (and to some extent still forming) rules about exactly how you can safely handle channels, which the compiler can't help with.
(I tried to keep an open mind, but I'm still of the opinion Erlang's processes with asynchronous mailboxes is better than Go's synchronous channels. Note that's two differences, not one; sync vs. async, and mailboxes vs. channels. And they are effectively synchronous, even when you set a buffer size, because there's still a hard cap on when the channel is full; semantically the difference between a 1-element sync channel and a 10-element sync channel is pretty minimal, you get the same crashes and failures either way if you misuse them, it just takes a bit longer in the 10-element case. Oh, and since "synchronous" seems to have had its meaning mangled here in the past few years, in this case it means that the writing and reading of a channel must coordinate.)
But if you're coming from a traditional Algol language, it's a big step forward. I'm sure coming to Go from Python or Lisp feels like a blast of fresh air, because it really is an improvement. And it gives you this without having to abandon your Algol roots, which most of the rest of your alternatives do (except Akka, though I don't how hard those are to use correctly since they're in a mutable language), and that is saying something.