It doesn't mean you should write your entire server stack in C vs calling a C function for heavy computation, but the idea that Java and Go approach 99% the speed of C/C++/Fortran is generally only true for programs that are not optimized for performance.
This is an implementation issue.
Nothing prevents a compiler vendor to offer the same capabilities to their language compilers.
Vectorization is not part of ANSI/ISO C or ANSI/ISO C++.
For the time being, do you want vectorization in Go? Write a tiny assembler routine. Done.
JVM? They are working on making it part of the reference JVM http://openjdk.java.net/projects/sumatra/.
.NET? While Microsoft does not offer anything, Mono has SIMD support since 2008, http://tirania.org/blog/archive/2008/Nov-03.html
Regarding writing assembly - that's fine, you could also write a routine in C and call it. The thrust of my comment is that it is untrue to argue that native Go and Java match the performance of C/C++. They don't. They might in the future.
The IBM J9 VM already has them.
http://duimovich.blogspot.ca/2012/11/packed-objects-in-java....
http://www.slideshare.net/mmitran/ibm-java-packed-objects-mm...
If you want really top performance for non-trivial cases, e.g. matrix multiplication, I guess you need to probably vectorise by hand and go down right to assembly level.
I think that is absolutely on the money?... but what if you are building one of those components?... or what if you are writing a very thin wrapper on one of those components, and it is brand new and only has C bindings?... or what if you need to be portable to dozens of different platforms, many of which don't share much toolchain overlap except for gcc?
> but I guarantee I'll probably leave a buffer overflow exploit open when trying to parse GET variables.
It's pretty easy to avoid that if you are worried about it. There are buffer/blob abstractions that give you "safe" interfaces with 0 risk of buffer overflow. Really, there is no good reason to have those unless you really are trading safety for performance.
> Or I can just do it in Java, and get all the performance and almost all the advantages of doing it in C.
Sometimes you can, sometimes you can't. It depends on the problem... and your levels of skill with both Java & C.
Exactly. String parsing is the biggest shortcoming in C that always gives me a second thought when I'm about to choose a language for a higher level application (especially if it incorporates user input as strings). Even such trivial thing as AT command parser is a pain in C. Of course, there are parser generators as Bison, but still it's tedious amount of work and usually not worth it.
If you really consider it, what 95% of people write these days is glue between various services, and the parts that do matter, where you need the most performance, are already written in C. The reason why Redis, MongoDB and Postgres have good C bindings, because they themselves are written in C.
So when it comes down to it all you are really doing is string parsing and string transporting, thats really the last thing you want to leave to C. I haven't done straight-C code that has required me to do a lot of string manipulation, but I guarantee I'll probably leave a buffer overflow exploit open when trying to parse GET variables.
Or I can just do it in Java, and get all the performance and almost all the advantages of doing it in C.