JRuby being faster than Ruby 1.8 proves nothing other than Ruby is not especially optimized.
V8 being dramatically faster than any other implementation of a dynamic language on JVM proves the point of Dart paper: x86 gives much more opportunity for optimization than jvm.
This is even more relevant if you consider the number of people who worked on jvm and the age of jvm compared to the same numbers for v8.
I don't think pointing out numerous inaccuracies from technical experts is nit picking. Your larger point may be true, I have no idea, but Charles was pointing out real misstatements about the JVM.
As I'm reading it, Nutter is blatantly misstating what the Dart guys say in order to create most of those "inaccuracies". For instance, he summarizes the Dart article as saying "2. JVM does not let you do what Java cannot do" and "3. A bytecode VM can't support all possible language features".
Where do the Dart guys say that? The entire Dart article is clearly about biases and limitations to _optimizations_ and not about what a language can or cannot do in the sense of Turing completeness. Nutter is creating a bunch of straw men here.
He also decides to ignore all but one of the examples the Dart guys give. They talk about unsigned math, tail call elimination, restartable conditions, continuations, and static/dynamic typing (I would add structured value types). He only responds to dynamic typing because that's where he might actually have a point.
Restartable conditions don't require any VM support that isn't also needed for normal exceptions. Even in CL implementations they're simply built on top of the normal non-local control flow construct (throw/catch) and dynamically scoped variables. And the latter are easy to implement in terms of try-finally even if not supported natively.
The tricky bit with restartable conditions is that you need to support them everywhere, or they're pretty useless. So they aren't going to be very interesting in a multi-language environment like the JVM even if they're easy to implement.
"""JRuby being faster than Ruby 1.8 proves nothing other than Ruby is not especially optimized. V8 being dramatically faster than any other implementation of a dynamic language on JVM proves the point of Dart paper: x86 gives much more opportunity for optimization than jvm."""
Reasoning: you're doing it wrong.
1) That JRuby is faster than Ruby 1.8/1.9 is not saying much.
Maybe x86 Ruby's implementation was not good enough from the start, and JRuby made a clean start. Perhaps you can make a x86 Ruby many times faster than JRuby with the right time.
What it does prove, by doing it, is that you can practically implement a language on JVM to be faster than a x86 language, despite the latter having much earlier head start and dev count.
2) That V8 is dramatically faster than any other implementation of a dynamic language on JVM DOES NOT PROVE the point of Dart paper that "x86 gives much more opportunity for optimization than jvm".
It could be just that implementations of dynamic languages on the JVM are toy projects with small teams working on them, while Google spend tons of dollars on a top-notch PhD team to work on V8. I certainly do now know of a JVM dynamic language with much money and team resources. Even stuff sponsored by Spring Source have much much less resources than Google's V8 team.
Also, check the benchmarks page you point to. Java is right up there in speed after C/C++/Fortran, and much much before x86 targeting v8. That's proof that nothing precludes a VM language being DAMN FAST.
And that's on the JVM, a VM almost set in stone, except of a few recent additions, and with a huge burden of backwards compatibility. Even better things could be achieved with a modern, unburdened, VM.
And the Dart team could even design it around the needs of the Dart language, most people would be happy with that, if it used a bytecode other languages could target.
Oh, and nothing precludes adding an AOT compilation system to a VM/JIT language.
Room for optimization suggests when time is taken you get a faster code. After all this time and all these optimizations the JVM is still terrible for 3D code and zero blockbuster games uses it. Sure, it's possible for JVM code to be on par with poorly optimized code, but that does not mean there is equal headroom for optimization. Worse yet, for web code you can't use the old standby of having the JVM call C or ASM code for truly critical code.
EX: You could probably get a minecraft clone to run faster on the JVM but that's because the game engine is crap not because JVM has any advantage.
"""Room for optimization suggests when time is taken you get a faster code. After all this time and all these optimizations the JVM is still terrible for 3D code and zero blockbuster games uses it."""
I don't think Sun was particularly good at optimizing in this particular task --or even interested.
They worked towards their actual customer use, ie. the server side.
It's not just 3D code, even desktop UI libs (Swing, JavaFX) and multimedia code where left without much (or any) love from Sun (/Oracle).
That doesn't mean a VM is unsuitable for fast 3D. Don't tons of 3D games use the Unity engine, which utilizes the Mono VM?
And it's not like critical 3D parts of the implementation cannot be written in plain old C/C++/ASM -- and exposed to the web programmers via some VM interface (a special set of 3D specialized opcodes? an intermediary 3D extension language + lib other vm languages will have to use? I dunno, it's however totally possible)
So if Mono (a VM language) can do fine in 3D games usage, it proves that nice 3D performance is not incompatible with a VM language --which is what the parent suggested, bringing up Java 3D performance as an example.
And again I am talking about headroom, it does not take state of the art graphics to make a great game, but it does take a non VM language for the graphics subsystem.
PS: Computers are FAST my cellphone would crush multimillion dollar super computers when I was in high school. So, generally trading speed for nicety's like virtual memory is well worth it. However, that does not mean we are avoiding the tradeoffs just accepting them with open arms.
V8 is orders of magnitude faster than JRuby on most benchmarks: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
Jruby is faster only on one.
That's why I call this nitpicking.
JRuby being faster than Ruby 1.8 proves nothing other than Ruby is not especially optimized.
V8 being dramatically faster than any other implementation of a dynamic language on JVM proves the point of Dart paper: x86 gives much more opportunity for optimization than jvm.
This is even more relevant if you consider the number of people who worked on jvm and the age of jvm compared to the same numbers for v8.