I would not be surprised if it turned out to perform extremely well - and perhaps even outperform Go. On the other hand, performance is not everything when it comes to writing large software systems. Again, my Erlang experience is that even if we are "hellishly slow" because every message is a copy in Erlang, it doesn't matter. For large software systems it turns out that the architectural design is what is the driving factor to program speed. How fast you pass a message is only part of the whole thing.

The real question to ask is how good a language is for the large scale software design. Certainly Java has proven itself to be there. Go is still young, but it specifically targets some of the problems in the same area as well. In my experience, debugging and the ease of doing so is also very important. And I don't know much about how easily this is to do in Go.

If it didn't, the fault would be mine. A dip to unsafe and it is effectively as bare metal as Go.

> The real question to ask is how good a language is for the large scale software design...

Agreed. A comparison with Java at this point would be unfair given the massive investment made by the industry in tweaking of the platform over nearly 2 decades. I think Go is a very promising language.

One simply hopes that the leading lights of the language/industry do not stoop to making threadbare (npi;) claims of superiority over other, equally viable, languages. After all, "it's just code". (PL religious wars are entirely boring.)

> debugging

Go has very good profiling and data race [1] detection tools. As far as debugging goes, I'm in the printf school of debugging (even on Java) and so far so good, so I can not speak to that.

[1]: it is not a pure CSP system. See this very interesting thread: https://groups.google.com/d/topic/golang-nuts/8k59RgkeJ6s/di... (grep for Andrei Alexandrescu of D fame and read on ..)

GDB has full support for Go now. So how easy debugging in Go is depends on your opinion of GDB, to some extent (the learning curve is steep but it's a powerful tool, IMO).

The GogC++ engineers programming the custom computing hardware running communicating over custom network hardware with custom network software disagree with your assessment that "architectural design" is all that matters to obtain performance. When your compute budget is around a billion dollars per year, constant factor speedups are highly relevant.

I would like to do that for kicks. What numbers would be interesting to look at in terms of benchmarking (throughput, response times, waiting times, etc.)?