"""Sure but that not the point. Dart would (just like JS) run on some kind of VM with a JIT."""
Actually that's the whole point, and that's what the Dart guys said they don't want to do and it's not fast enough.
"""If the[y] would open the code for that VM it would have problems just like the JVM has."""
Like what? Name one (1) problem the JVM has had because of making bytecode available as a target.
That other languages trying to run on the JVM had some performance problems and needed some opcodes and stuff is no a problem the JVM shared --it was an optimization request. And the theoretical Dart VM would not even have to have those problems, because unlike Java/JVM, it can be designed from the start to be dynamic.
And it's not like there weren't totally competent language implementation targeting the JVM before invokedynamic and other "nice-to-haves".
"Actually that's the whole point, and that's what the Dart guys said they don't want to do and it's not fast enough."
Im 99% sure that the Dart team is building a VM with a JIT for Dart. There goal is to be faster then JS this will not be possible without some kind of JIT. Like I said, the question is if the have some kind of bytecode (any IR) that can be targeted. How else can the make a it fast? They send the sourcecode from the server to the client there is no time for a fully optimizing compiler.
"Like what? Name one (1) problem the JVM has had because of making bytecode available as a target."
Well the JVM dosn't have any problems the language running on it have problems.
"And the theoretical Dart VM would not even have to have those problems, because unlike Java/JVM, it can be designed from the start to be dynamic."
Dynamic typing is not the only problem of the JVM. Implmenting everything that every programming language needs is not possible. Sure you can design any VM and with time make it better for more and more languages.
This however comes with a price, for example VM complexity. Cliff Click who worked on the original Sun JVM and did a complete rewrite of it for Azul talks about this, why do you think it to that many years until the JVM bytecode changed? Complexity. If you really want to evolve the language your bytecode will have to change witch means the VM must change two. If Dart ran on an open Dart VM it would be much harder to change the VM and the overall implmentation.
My Final points:
(1) Designing a fast VM (bytecode, JIT, GC ....) is hard.
(2) If you want to make a VM that is good for many languages it even harder.
(3) Goole wants Dart not a generic VM (or at least the rather have a fast Dart short term then a generic VM with a Dart impmentation that takes much longer to develop and much more work to maintain.)
(4) I agree that we want generic Web VM.
(5) Somebody (w3c for example) should start a process to work on something like this. Gathering proposals, encourage smart people to thinkg about this.
> They send the sourcecode from the server to the client there is no time for a fully optimizing compiler.
The solution that the Dart VM and other JS VMs to is to compile twice: you do a very fast simple compile so that you can start executing code quickly and reduce start-up time. Then you find frequently-used functions and recompile them using a more advanced optimizing compiler. This is why many modern VMs have a "warm-up" period: code will get faster over time as it gets recompiled more optimally.
Actually that's the whole point, and that's what the Dart guys said they don't want to do and it's not fast enough.
"""If the[y] would open the code for that VM it would have problems just like the JVM has."""
Like what? Name one (1) problem the JVM has had because of making bytecode available as a target.
That other languages trying to run on the JVM had some performance problems and needed some opcodes and stuff is no a problem the JVM shared --it was an optimization request. And the theoretical Dart VM would not even have to have those problems, because unlike Java/JVM, it can be designed from the start to be dynamic.
And it's not like there weren't totally competent language implementation targeting the JVM before invokedynamic and other "nice-to-haves".