The Unreasonable Effectiveness of C (2013)
>Every time there is a claim of "near C" performance from a higher level language like Java or Haskell, it becomes a sick joke when you see the details. They have to do awkward backflips of syntax, use special knowledge of "smart" compilers and VM internals to get that performance, to the point that the simple expressive nature of the language is lost to strange optimizations that are version specific, and usually only stand up in micro-benchmarks.<p>I see this kind of statement a lot, and it simply does not hold up to even a cursory look.  Where are the awkward backflips of syntax, special compiler or VM knowledge, or version specific optimizations here?<p><a href="http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=mandelbrot&lang=java&lang2=gcc&data=u32" rel="nofollow">http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...</a><p><a href="http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=fasta&lang=java&lang2=gcc&data=u32" rel="nofollow">http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...</a><p>Why are there so many java web frameworks/libraries/servers that offer performance close to C?<p><a href="http://www.techempower.com/benchmarks/#section=data-r9" rel="nofollow">http://www.techempower.com/benchmarks/#section=data-r9</a><p>>Critically important to developer efficiency and productivity is the "build, run, debug" cycle.<p>This is a pretty bizarre claim.  Sure, having an equally archaic and primitive process but 10 times slower is obviously worse (C++), but that doesn't mean having an archaic and primitive process is good if it is fast.  I rarely ever run my code, much less debug it.  Freeing myself from that horrible way of working was one of the greatest things about working in a language with a useful type system.