Yeah, the limitation isn't hardware, but utilisation thereof. Maybe Go will change that; but I don't see it touting concurrent code as becoming trivial - just easier. (maybe I'm wrong?)
Server loads are typically embarrassingly parallelizable, e.g. serving concurrent web requests. I mean, consider, are you maxing out all 8 cores? Multicore utilisation is hard, in general. So desktop cpus pretty much stalled at quad-core (I expect ARM chips are doing likewise as we speak).
Concurrency with messaging is rather trivial, because it does away with the vast majority of the hard parts (but not all of them). Go is easy in that regard for the same reasons Erlang is easy .
I looked into Erlang in some depth, and found its concurrency ability was due to shared-nothing modules (which smalltalk also has), which I think you refer to with "messaging". Race conditions can still occur, which I guess you include with "not all of them". Plus, in Erlang this was found to not address all concurrency problems, and so a software transactional database is included as standard.
Looking at the details, I don't think general concurrency is a solved problem. Looking at the results, if it was, we'd have much better utilisation of multi-core architectures by now than we do. For example, 32 core x86, clocked ultra-low, for extraordinarily low power consumption.
Actually, another issue is that message passing might work better with cores with their own RAM, so the modules can work independently.
I think there's a huge amount of kool-aid around concurrency "solutions" - functional programming, erlang, and now Go. Because concurrency is so valuable, if Go really does make it trivial, we it should quickly dominate all other languages. But it seems to me that concurrency is still a hard problem.
As someone who has shipped two production systems in Erlang, one for a fortune 100 company, another for a floundering former tech giant, I don't think it is nearly as kool-aid as you think.
It is out there, a lot, used in trading houses, used in running credit reports, used for facebook chat, used to route cell phone calls, used as the back-end component to gobs of system (CouchDB, RIAK).
Erlang has a very similar culture background to Go, it wasn't built for Academia, it was built to solve issues right in front of its creators, real world problems they struggle with everyday, inside Google and Erickson respectively.
Both are un-sexy, get-er-done type languages. Erlang has found happy homes all over the place, and I have no doubt Go will do at least as well -- most likely far better.
Server loads are typically embarrassingly parallelizable, e.g. serving concurrent web requests. I mean, consider, are you maxing out all 8 cores? Multicore utilisation is hard, in general. So desktop cpus pretty much stalled at quad-core (I expect ARM chips are doing likewise as we speak).