But "dependence" on VM is nothing tragic if the GC is not in the game. If you'd imagine a VM without GC then what remains is just the potential for run-time JIT and optimization which can actually be a good thing! There's a long history of p-code interpreters which provided the more compact code, see http://en.wikipedia.org/wiki/UCSD_Pascal and http://en.wikipedia.org/wiki/Microsoft_P-Code At that time tracing and JIT would have been too heavy thing to do but today it could maybe be interesting to have something like that.
And as far as I know, Go doesn't "depend" on VM but does on GC, but D also generates the native code but doesn't have to use GC and I think that is an important advantage for such a kind of the language.
But "dependence" on VM is nothing tragic if the GC is not in the game. If you'd imagine a VM without GC then what remains is just the potential for run-time JIT and optimization which can actually be a good thing! There's a long history of p-code interpreters which provided the more compact code, see http://en.wikipedia.org/wiki/UCSD_Pascal and http://en.wikipedia.org/wiki/Microsoft_P-Code At that time tracing and JIT would have been too heavy thing to do but today it could maybe be interesting to have something like that.
And as far as I know, Go doesn't "depend" on VM but does on GC, but D also generates the native code but doesn't have to use GC and I think that is an important advantage for such a kind of the language.