Geez, this post is full of complete nonsense and FUD when it comes to programming languages and their performance characteristics. I won't comment about the language design (I kind of like C#, but it's beyond the point), but the facts:
* C#, and specifically microsoft implementation of it is absolutely horrible. The AOT part is ok, but the JIT is incredibly dumb. There are good reasons why it is the way it is, but it's ridiculously slow compared to Java (and yes, you're legally obliged not to do this comparison)
* MRIs Ruby GC collector until 2.0 had bugs which prevented it from having good performance, even asymptotically. To be honest, CPython had it until 2.6 too. That means that if you allocate objects rapidly you can end up in a O(n2) situation where each n allocated objects end up taking more and more time.
* Ruby and MRI in particular is nowhere near good performance. But you can throw more hardware on the problem always.
* I would like to see some data about "StackOverflow is fast because it's on .NET", it definitely does not fit with my view of how fast/slow libraries/VMs perform.
To be honest, language speed often does not matter. Java has pretty decent VMs, like hotspot and yet a lot of Java code is horribly slow, because libraries are badly written (think eclipse).
Also I'm personally terrified with ruby's security stories recently (and yes, it's both ruby and rails at fault)
For a post accusing another of FUD, it would help if you got more of your own details right: C# doesn't have an AOT or JIT compiler - all compilers that I'm aware of always compile it to IL. You're right that the .NET JIT has historically focused on startup speed rather than pure speed, but there are many factors that affect performance (e.g. C#'s defaulting methods to non-virtul may mitigate the lack of hotspot-like optimization; value types and the resulting lack of boxing/unboxing may likewise have a positive impact; ditto for reified generics). What in particular strikes you as "horrible" about Microsoft's implementation?
We did quite a lot of benchmarks about various programs (like Python interpreter written in RPython compiled to C#) and the performance was pretty bad. There were various issues, some avoidable some unavoidable, like Exceptions being very very slow (and being essentially for free on Java). I don't think it's possible to summarize it without writing a small novel and I don't care enough, but the JIT is as far as I know a direct IL-to-ASM compiler with very little optimizations or not at all. This puts a serious ceiling on what can be fast and what cannot be fast. In particular the escape analysis is either non-existant or very weak.
The AOT part is exactly C# -> IL and then it's later compiled to assembler.
* C#, and specifically microsoft implementation of it is absolutely horrible. The AOT part is ok, but the JIT is incredibly dumb. There are good reasons why it is the way it is, but it's ridiculously slow compared to Java (and yes, you're legally obliged not to do this comparison)
* MRIs Ruby GC collector until 2.0 had bugs which prevented it from having good performance, even asymptotically. To be honest, CPython had it until 2.6 too. That means that if you allocate objects rapidly you can end up in a O(n2) situation where each n allocated objects end up taking more and more time.
* Ruby and MRI in particular is nowhere near good performance. But you can throw more hardware on the problem always.
* I would like to see some data about "StackOverflow is fast because it's on .NET", it definitely does not fit with my view of how fast/slow libraries/VMs perform.
To be honest, language speed often does not matter. Java has pretty decent VMs, like hotspot and yet a lot of Java code is horribly slow, because libraries are badly written (think eclipse).
Also I'm personally terrified with ruby's security stories recently (and yes, it's both ruby and rails at fault)