People are advocating Go because it delivers. It has great concurrency primitives (channels), it is "boring" language syntax wise, and it is fast.
Beyond that, it deals with a lot of the 'ugly' things around the edges of other languages. Dependency management, build management, deployments... all these IMHO are much more well thought out in go.
It delivers? Lol. The GC used to suck for 32 bit systems and it still sucks for realtime. As opposed to Nimrod's which pretty much guarantees a maximum pause time of 2 milliseconds -- independent of the heap size. And that's only the start: Go also lacks generics and meta programming in general. And its memory/concurrency model is just as racy as Java's.
Go was never designed for "realtime". Also, 32 bits wasn't the main compiler focus, 64 bits was. This problem being mainly fixed with the 1.1 release, this is a non issue now. The memory model seems pretty well defined without being too restrictive, with the recent addition of the race detector.. Go looks well equiped for this kind of problems and some pretty interesting projects are there to prove it.
You are correct on some points. 32 bit was broken, realtime is a non-feature. It does (by design) lack generics and meta programming (Pike talked about these at length at one point).
I have to disagree on the concurrency model, I think message passing channels are a much more natural primitive to model concurrency in, and goroutines are exceptionally light.
EDIT: When you talk about nimrod, you might go ahead and mention you are the designer of nimrod... it might color your judgement.
"Nobody is smart enough to optimize for everything, nor to anticipate all the uses to which their software might be put." -- Eric Raymond, _The Art of Unix Programming_
Go's primary niche is server software, and in that niche, it is gaining in popularity and has the backing of a large company. For servers, neither support for a 32-bit address space nor real-time support is important.
Does support for generics really matter when the language has built-in support for the most common collection types?
The allowance of shared mutable memory between goroutines does worry me somewhat.
Beyond that, it deals with a lot of the 'ugly' things around the edges of other languages. Dependency management, build management, deployments... all these IMHO are much more well thought out in go.