Go is excellent for prototyping ideas, which is why it is my "language of choice" at the moment. But your argument falls flat when considering deploying "large scale" systems, which have multiple dimensions of ceremony before hitting production.

I disagree. I build very large scale systems. I think that large scale systems should be constructed out of small components which are loosely coupled distributed components with strong contracts between them. These components are ideal for encapsulating in small standalone go components.

That is a viable approach and I share your affinity for that type of architecture, but insisting that it is the only way to build large scale systems is not reasonable. In real life, for example, you have clients and clients have their preferences or requirements or existing systems. And system architects also like having choices.

And speaking of choice in context of massively concurrent CSP systems, Erlang is (as of now) the superior choice for that sort of system architecture.

I agree. I'm not suggesting that it's the only way, but a suitable and generally successful way.

Erlang is ok, but the staff don't scale. Have you tried finding Erlang programmers?

> [Erlang] doesn't scale.

http://basho.com/products/riak-overview/

I think you mean Erlang's strict CSP -- share nothing -- is not as efficient as shared memory systems such as Go. That is a fact and by design it is a feature and not a bug. Nine 9s: http://pragprog.com/articles/erlang

> Have you tried finding Erlang programmers?

Go looks easy but it is a subtle language. Brad F. writes a server and it performs. Mr. X writes one and it crawls. Go figure.

Erlang doesn't scale as in Erlang doesn't scale to larger projects when you require lots of people working on them. I doubt we could put our 2MLOC trading platform into Erlang and get away with it.

It certainly scales from a technology point of view.

Go is simple enough to allow Mr X's code to go through a review by Brad F until Mr X gets the point.