As much as I respect Nutter's achievements and his jvm chops, his response reads like nitpicking based on his misreading/misunderstanding of what Dart guys wrot

As much as I respect Nutter's achievements and his jvm chops, his response reads like nitpicking based on his misreading/misunderstanding of what Dart guys wrote and what they meant by it. The position of Dart guys is simple: by compiling an arbitrary language (Dart in this case) to x86 (or whatever native arch the browser is running on) they can get a much faster code than compiling to an abstract VM, like JVM or .NET or parrot. It's not a controversial statement: JVM ultimately compiles to x86 too, so whatever optimization tricks JVM does to generate fast code can be used by a compiler that goes directly from source to x86. The opposite, however, is not true: JVM does introduce an additional layer and fixes in stone many things other than just the instruction set that make compilation of some scenarios from jvm to efficient x86 impossible. And you can't fix that without introducing incompatibilities i.e. breaking existing code. One example of this is class format layout: it has known problems, many of which were fixed in Dalvik. Dalvik, not being jvm, can fix them, but jvm can't without fragmenting the platform. Nutter doesn't exactly contradict the fact that targeting x86 directly results in faster code but all his nitpicking is designed to give that impression. For example, because Dart paper mentioned in passing that JRuby can't be made as fast as native Ruby, he tears into that because JRuby is actually close to Ruby 1.8 in performance. Which, of course, proves nothing. The best JavaScript implementation on JVM is on par, performance-wise, with the old, pre-V8 JavaScript interpreters. V8, Nitro, and Mozilla's various Monkeys all beat that 10-20x, easy. Nutter latches to the unfortunate example Dart paper gave but completely ignores other examples that do show that targeting x86 is, indeed, 10-20x win for dynamic languages. When the paper says that jvm lacks features to implement at least some possible language features efficiently (like built-in instructions for tail-calls) and you can't do anything about. Nutter interprets it as some literal "JVM does not let you do what Java cannot do" but instead of addressing the point (lack of certain primitives needed for fast implementation of certain construct) he again use the JRuby-Ruby 1.8 speed parity as somehow showing Dart guys are wrong. In "A bytecode VM is more than just bytecode" he uses turing-machine argument: both jvm and x86 is turing complete therefore they're just as good. He tops with really weird statement like "Compiling to x86 works best if your feature set fits x86" (if your feature set doesn't fit x86, there it doesn't fit anything). He also brings invokedynamic as a pro-JVM argument disregarding the fact that it's a recent addition to JVM that breaks backwards compatibility - you can't run Java program that uses invokedynamic on older JVMs because they don't understand it. I could go on. This post is just nuts. Here's the real kicker: Nutter is the same guy who develops Duby and Mirah, a static Ruby-look-a-likes. Why does he develop Mirah? From http://www.mirah.org/ http://www.mirah.org/: "No performance penalty Because Mirah directly targets the JVM’s type system and JVM bytecode, it performs exactly as well as Java."