I take significant issue with this paragraph: When you write something to be fast in C, you know why it's fast, and it doesn't degrade significantly w

I take significant issue with this paragraph: When you write something to be fast in C, you know why it's fast, and it doesn't degrade significantly with different compilers or environments the way different VMs will, the way GC settings can radically affect performance and pauses, or the way interaction of one piece of code in an application will totally change the garbage collection profile for the rest. The implementation of malloc & free that your C implementation uses significantly impacts performance (both time and space) just like the choice of GC implementation in other languages. It is not uncommon for memory fragmentation to be a serious problem for large or long-running C programs, and at the point that you have to start worrying about that and working around it, you've broken the abstraction in just the same way that the author complains about for Java, Erlang, Haskell, etc. Also, as others have pointed out, performance can also depend significantly on how well C's machine model maps to the actual machine architecture you're running on.