Golang performance profile is very different from Java. It's speed is closer to C++, garbage collection optimized for latency, not bandwidth, very low startup time comparable with typical native code.

You can actually get a performance profile very much like Go's out of Java...

* Inasmuch as you can make a blanket statement like this about a language, Go's speed is very much comparable to Java's.

* Java has a huge number of garbage collectors available. You're just talking about the default, but there are extremely low-latency GCs.

* Java has a bunch of ahead-of-time compilers; thanks to Android this might be the most common deployment of Java.

Even green threads were tried (and sensibly abandoned) in Java before.

I think people may not be aware of all the options available in the Java ecosystem, but other than sized types, which are theoretically coming to Java 10, there isn't much performance-wise that Go does and Java doesn't.

Just because a language is compiled doesn't mean it will approach C++ speeds. The GC itself is a hard limit on perf. What I've seen in practice:

1x time: C

1.5x time: C++ (with smart pointers)

~2x time: Objective-C (almost everything is a heap smart pointer)

3x time: Java, Golang (optimized GC languages)

Yes Erlang does, strictly for execution throughput, but less so for concurrency handling. That is also a solveable problem. It just so happens to be a problem neither Ericsson nor ESL have been interested in solving.

Remember, Erlang was first and foremost developed as a programming language (and runtime) to run Ericsson's phone switches.

Session establishment for PSTN can be relatively expensive (much in the way of TLS handshakes), so concurrency and shared-nothing memory model together allowed for real-time streaming to keep on working no matter what else happened. The three main features of a PSTN switch are, after all:

1. Reliable call switching

2. Reliable real-time throughput

3. Reliable billing and accounting data generation

We don't think much of throughput these days, when any home office switch has gigabit ports and 40Gb+ backplane. As far as I know, maximising throughput bandwidth was not a primary consideration with Erlang. Reliable real-time streaming is much more about guaranteed latency - and incidentally, optimising between latency and throughput tends to be all about tradeoffs.