Benchmarks are all you need to know unless a language runtime has IO problems. Fewer instructions and less memory mean fewer servers. Benchmarks are really good at predicting general performance. Languages with slow benchmarks need more servers to run your app. Languages with fast benchmarks need far fewer servers to run your app. This fact is so obvious and testable that I don't know why slow-language people bother throwing up the argument that benchmarks aren't everything.
Repeat after me: languages don't have speed.
Maybe to someone who is just now getting into the industry, but it wasn't long ago JS had no speed.
Python also varies in speed over time and implementation. Implementations have speed. There are reasons that people use "slow languages". It's not just developer happiness. You really do have to look at performance holistically.
If you want to speak to microbenchmarks, I can. For example, CPython's std lib JSON processing is done in C. It's very fast. As of Go 1.2, PyPy blew the doors off Go in my tests processing 10,000 JSON records. CPython 2 & 3 also beat Go in my tests as well. What's this mean? Does it mean Go is a slow language? Well, it's one microbenchmark vs another. It really doesn't mean much to your application.
"I don't know why slow-language people bother throwing up the argument that benchmarks aren't everything."
I'd go even further than 'aren't everything'. Benchmarks that aren't your application do not mean anything.
Many are ignorant of how CPython is even built and are shocked when I show them how fast many standard library modules are. It's just not so simple. Don't believe the hype.
What benchmarks? Benchmarks are specific to the application area. Computing n-body simulations are not good benchmarks for a concurrent application that servers web requests, connects to databases, and processes credit card data.
