For C/C++, don't use a memory-unsafe language to speak to networks. (The fact that so many things already do is no excuse and adequate demonstration of why. Also arguably more true of C than C++ but I'm not particularly impressed with claims that C++ is safe if you just "do it right" because that's the sort of gap you can drive a truck through.) Rust is still a bit shy of web libraries, and may be overkill for some use cases, but otherwise, go for it. Go for it with Java too.

However, the performance gap between Go and Rust is much smaller than the gap between Go and a dynamically-typed language, even one JIT'ed to the n'th degree, and the gap between Go and Java generally lost in the noise [1]. Between Go, Java, and Rust, you've probably got a good case that you'll get to more-or-less production-ready code fastest in Go. (And yes, "more-or-less" is a gap big enough to drive a truck through too. I preemptively pretty much agree with everything anybody might care to write about that issue in reply. :) )

[1]: I suppose I should point out that a perf gap of 2 or 3 is "generally lost in the noise". In the real world what tends to control which such language has the better implementation of something for most tasks is who has taken more time to write an optimized version. It's when you start getting up to the 10x-25x range that the gap between Go and a dynamic language can be that it's not really "lost in the noise" anymore; in that case, the faster language can end up simply faster than the slow language even if the slow language is given a lot of extra love (assuming no "change to a different language" shenanigans).

To be clear, I am not suggesting Go specifically, although it is certainly a very good choice and the article this thread is linked to makes its own good arguments in favor of Go. Java 8 also has some very high-productivity modern web application frameworks, as do several other high-performance platforms. I generally advise selecting anything within the top third—what I loosely call the high-performance tier—of our benchmarks project. There are a bunch of options there, Go included.

Making a platform selection that is informed, in part, on the language/platform's performance is a reasonable thing to do. As long as you can be equally productive (or even if you are a little less productive) with a high-performance platform, you will likely endure less pain during the initial several months once your system goes live and considerably less pain over the long haul.

Plus, it's really great to have a wicked-fast web app with very little performance-tuning effort.

Because Go is a fast, fun and productive language. It is important to have all the three :-)