This kind of article is always a minefield and a huge bait for debates, even more when it's part of the advocacy for some new programming language (who doesn't love language fights?). It's important to be very precise, adhere to standard and well-known terminology, be very clear about the scope of each claim, have necessary disclaimers about benchmarks etc. or you are just asking for trouble. :) Your (kkowalczyk's) reply has some good points ("...if your feature set fits x86" indeed Charles was tired or something to write that), but it does have several flaws too. You get the concept of "backwards compatibily" completely wrong: adding a new feature like invokedynamic that prevents NEW code to run on OLD runtimes does not break BW compat. Java's track record in BW compat is almost perfect (modulo bugs). JRuby's results in the language shootout are produced with HotSpot Client, that's why they are so bad, JRuby depends massively on HotSpot Server. For benchmarks that critically depend on certain features like fixnums, a VM like YARV will certainly beat JRuby easily; but this doesn't mean "general-purpose VM cannot compete with specialized VM", it only means "VM without special support for feature X may not compete with VM that has X, in a benchmark that stresses X".
The real discussion in the performance aspect of "bytecode VM" vs. "language VM" is much more subtle. A "language VM" will not convert source code directly to native code either; it will use one or more Intermediary Representations, from ASTs to classic SSA LIR/HIR. So it's easy to argue that these are equivalent to bytecodes; and one can just design some bytecode format that is basically an externalized form of your IR, then there's no disadvantage of performance or limitation for two-stage compilation with a JIT. But now the discussion moves to evolution and flexibility. IR forms can be completely changed in new releases of the compiler/VM, because they are internal. But as soon as you're tied to an external representation, you're stuck to evolving that much more conservatively, or with much extra effort, not only for the VM but for the entire third-party toolchain ecosystem that targets the bytecode. This is the major problem that the Dart article should have raised. There's still the possibility of creating some truly universal bytecode - LLVM's bitcode may fill these shoes for unmanaged languages; and something similar could be designed for managed languages although that's harder because a managed heap and memory model necessarily means some set of restrictions that will get in the way of some languages, at least the very lowest-level ones. Dart is Google's attempt to provide a better managed language for the web (without bytecode), while NaCl is their attempt to provide a better support for unmanaged languages (with either native code / NaCl or LLVM bitcode / PNaCl], so they're trying to cover all corners and it will be very interesting to see how each of these developments work out.
The real discussion in the performance aspect of "bytecode VM" vs. "language VM" is much more subtle. A "language VM" will not convert source code directly to native code either; it will use one or more Intermediary Representations, from ASTs to classic SSA LIR/HIR. So it's easy to argue that these are equivalent to bytecodes; and one can just design some bytecode format that is basically an externalized form of your IR, then there's no disadvantage of performance or limitation for two-stage compilation with a JIT. But now the discussion moves to evolution and flexibility. IR forms can be completely changed in new releases of the compiler/VM, because they are internal. But as soon as you're tied to an external representation, you're stuck to evolving that much more conservatively, or with much extra effort, not only for the VM but for the entire third-party toolchain ecosystem that targets the bytecode. This is the major problem that the Dart article should have raised. There's still the possibility of creating some truly universal bytecode - LLVM's bitcode may fill these shoes for unmanaged languages; and something similar could be designed for managed languages although that's harder because a managed heap and memory model necessarily means some set of restrictions that will get in the way of some languages, at least the very lowest-level ones. Dart is Google's attempt to provide a better managed language for the web (without bytecode), while NaCl is their attempt to provide a better support for unmanaged languages (with either native code / NaCl or LLVM bitcode / PNaCl], so they're trying to cover all corners and it will be very interesting to see how each of these developments work out.