4 ms·

Here's what I don't understand: why is there any focus on alternative VMs for specific languages? Surely all this effort should be going into a VM for some kin

Here's what I don't understand: why is there any focus on alternative VMs for specific languages? Surely all this effort should be going into a VM for some kind of highish-level intermediate representation that's trivial to generate from any source language? That way no language has a monopoly and there can be peace on Earth. It seems odd to be arguing for generic computation abilities in the place where most "computation" is done nowadays. Can you imagine what could be achieved if the browser vendors and standards bodies put business considerations aside and spent a good couple of years designing such a thing? We could have an almost endless list of goodies: threads, code isolation, multiple number types... Just like Intel, AMD, and the rest in effect control (much to Alan Kay's despair) hardware architectures, the vendors & standards bodies are a sort-of natural cartel controlling upwards of, what, 50%? 80%? the code end users actually interact with. The quality of the decisions they make has deep repercussions beyond the tech community and it's simply not possible for any of us to know what they all are. Even if they were bona-fide saints, this would still be too much power to tie up in such a small group.

danschuller 12y ago
Agreed. A more generic VM seems the way to go. .NET's CLR does well supporting a wide array of different languages very well C#, F#, IronPython, IronRuby etc
frozenport 12y ago
I agree, I thunk this isnt being done because browser vendors believe that the intermediate common language is Javascript and that if they fix JS performance they are killing two birds with one stone. This isnt true because JS lacks many features like synchronization primitives.
- frozenport 12y ago
  Spelling is hard on my cellphone. Would be nice to have a longer editing window.
- azakai 12y ago
  Synchronization primitives are being suggested for addition to JS, https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/ https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p...
BrendanEich 12y ago
Ecma TC39 is working on all the goodies you mention, and more (yes, even threads with shared ArrayBuffer memory). In a couple of years, you might have some of them in top JS engines. Starting fresh would take many more than two years, and very likely end in tears. This assumes browser vendors could spare the effort to do JS and the new thing (most cannot, even Google arguably can't). For why the best VMs are focused on one language, see https://www.dartlang.org/support/faq.html#q-why-didnt-google-build-a-bytecode-vm-targetable-by-multiple-languages-including-dart https://www.dartlang.org/support/faq.html#q-why-didnt-google... and https://www.dartlang.org/articles/why-not-bytecode/ https://www.dartlang.org/articles/why-not-bytecode/ from the Dart team. See also http://mozakai.blogspot.fr/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.fr/2013/05/the-elusive-universal-web... from Alon Zakai of Mozilla.
- lorddoig 12y ago
  Those links are very interesting, I didn't know it was such a common question. However I still wonder - is bytecode the only way to go about this? Every compile-to-JS language I've used has either been sugar over JS or had JS's semantics/syntax seeping through the cracks...what if the base language was a Lisp? There's a big difference between being bound to the semantics of a language like JS or dart and those of Lisp. I have no doubt that a new VM would be a herculean undertaking and be riddled with all sorts of problems, but I remain unconvinced that it wouldn't pay off in the end. Maybe I'm being naive, but if what we're doing now really is as good as it gets then it seems either I'm much more ignorant to the issues at play than I thought or this hole is significantly deeper than even I imagined.
  - BrendanEich 12y ago
    JS's syntax wouldn't seep through (backward?) into the compile-to-JS language, which would treat it as safe assembly. You're right that semantic gaps in JS could make the compiler for Blub fall into the Turing tarpit, needing costly runtime -- see Babel's "spec" vs. "loose" (I hope I have those right) modes. The answer here is to fill semantic gaps in JS, which we're doing in TC39. Evolution can fill gaps in JS, and has: typed arrays are one example; generators another. More to do, but it's not as if the distance x cost to suffer in filling gaps is greater than the distance x cost of doing a de-novo VM among all browsers, on top of keeping JS going. It's much, much less.
deathanatos 12y ago
> Here's what I don't understand: why is there any focus on alternative VMs for specific languages? Surely all this effort should be going into a VM for some kind of highish-level intermediate representation that's trivial to generate from any source language? That way no language has a monopoly and there can be peace on Earth. I've always wondered: why not LLVM? It's low-level, so the speed is there, and I think should be trivial to compile as it arrives at the browser. Tons of stuff already compiles to it. You can compile it to JS. Of course, you'd need to make sure it doesn't make a syscall that's not allowed (and I'm not sure how hard that is), and that it has bindings into JS APIs and/or the DOM, but aside from that… I'm sure some people will suggest things like the JVM or the .Net CLR, but I feel like those have certain qualities (e.g., GC) that don't appeal to all languages.
- tinganho 12y ago
  I have been wondering the same thing. JS might be a good language. But we should still have a choice to choose other languages. I'm seeing efforts with asm.js turning JS into a byte code language aka. LLVM IR. I'm not sure if turning JS into a byte code language is the best way either. It is still too high-level language. And it seems like a ugly hack.
- Touche 12y ago
  > I've always wondered: why not LLVM? Because LLVM is not hardware independent.
  - azakai 12y ago
    Also, LLVM IR has undefined behavior and was not designed as a network format (it's large). LLVM is simply not a good starting point for the problem here, nice as LLVM is for what it does do well.
  - comex 12y ago
    That didn't stop PNaCl. (Which has its share of problems, of course, but I think it makes the hardware dependence meme pretty moot.)
- 12y ago
hrktb 12y ago
There was a talk by Matz about ruby 2 and how they were tweaking the runtime to improve garbage collection. I don't remember the details but a lot of work went into seeking the best collection behavior to match the language, optimizing for the most common cases, checking the patterns favored by the language and tweaking the behavior to ease these cases, etc. The intersting thing is that there's jruby for the JVM, and it makes the different tradeoffs surface better. Looking at this benchmark for instance [0] it's easy to see how the tweaked runtime gives a very different performance profile from the generic VM. I have a feeling the highish-level intermediate layer you are talking about would be equivalent to have only some specific tradeoffs despite the optimizations that could be done on a language per language basis. [0]http://benchmarksgame.alioth.debian.org/u64q/jruby.php http://benchmarksgame.alioth.debian.org/u64q/jruby.php

danschuller 12y ago

Agreed. A more generic VM seems the way to go. .NET's CLR does well supporting a wide array of different languages very well C#, F#, IronPython, IronRuby etc

frozenport 12y ago

I agree, I thunk this isnt being done because browser vendors believe that the intermediate common language is Javascript and that if they fix JS performance they are killing two birds with one stone. This isnt true because JS lacks many features like synchronization primitives.

frozenport 12y ago
Spelling is hard on my cellphone. Would be nice to have a longer editing window.
azakai 12y ago
Synchronization primitives are being suggested for addition to JS, https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/ https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p...

BrendanEich 12y ago

Ecma TC39 is working on all the goodies you mention, and more (yes, even threads with shared ArrayBuffer memory). In a couple of years, you might have some of them in top JS engines. Starting fresh would take many more than two years, and very likely end in tears. This assumes browser vendors could spare the effort to do JS and the new thing (most cannot, even Google arguably can't). For why the best VMs are focused on one language, see https://www.dartlang.org/support/faq.html#q-why-didnt-google-build-a-bytecode-vm-targetable-by-multiple-languages-including-dart https://www.dartlang.org/support/faq.html#q-why-didnt-google... and https://www.dartlang.org/articles/why-not-bytecode/ https://www.dartlang.org/articles/why-not-bytecode/ from the Dart team. See also http://mozakai.blogspot.fr/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.fr/2013/05/the-elusive-universal-web... from Alon Zakai of Mozilla.

lorddoig 12y ago
Those links are very interesting, I didn't know it was such a common question. However I still wonder - is bytecode the only way to go about this? Every compile-to-JS language I've used has either been sugar over JS or had JS's semantics/syntax seeping through the cracks...what if the base language was a Lisp? There's a big difference between being bound to the semantics of a language like JS or dart and those of Lisp. I have no doubt that a new VM would be a herculean undertaking and be riddled with all sorts of problems, but I remain unconvinced that it wouldn't pay off in the end. Maybe I'm being naive, but if what we're doing now really is as good as it gets then it seems either I'm much more ignorant to the issues at play than I thought or this hole is significantly deeper than even I imagined.
- BrendanEich 12y ago
  JS's syntax wouldn't seep through (backward?) into the compile-to-JS language, which would treat it as safe assembly. You're right that semantic gaps in JS could make the compiler for Blub fall into the Turing tarpit, needing costly runtime -- see Babel's "spec" vs. "loose" (I hope I have those right) modes. The answer here is to fill semantic gaps in JS, which we're doing in TC39. Evolution can fill gaps in JS, and has: typed arrays are one example; generators another. More to do, but it's not as if the distance x cost to suffer in filling gaps is greater than the distance x cost of doing a de-novo VM among all browsers, on top of keeping JS going. It's much, much less.

deathanatos 12y ago

> Here's what I don't understand: why is there any focus on alternative VMs for specific languages? Surely all this effort should be going into a VM for some kind of highish-level intermediate representation that's trivial to generate from any source language? That way no language has a monopoly and there can be peace on Earth. I've always wondered: why not LLVM? It's low-level, so the speed is there, and I think should be trivial to compile as it arrives at the browser. Tons of stuff already compiles to it. You can compile it to JS. Of course, you'd need to make sure it doesn't make a syscall that's not allowed (and I'm not sure how hard that is), and that it has bindings into JS APIs and/or the DOM, but aside from that… I'm sure some people will suggest things like the JVM or the .Net CLR, but I feel like those have certain qualities (e.g., GC) that don't appeal to all languages.

tinganho 12y ago
I have been wondering the same thing. JS might be a good language. But we should still have a choice to choose other languages. I'm seeing efforts with asm.js turning JS into a byte code language aka. LLVM IR. I'm not sure if turning JS into a byte code language is the best way either. It is still too high-level language. And it seems like a ugly hack.
Touche 12y ago
> I've always wondered: why not LLVM? Because LLVM is not hardware independent.
- azakai 12y ago
  Also, LLVM IR has undefined behavior and was not designed as a network format (it's large). LLVM is simply not a good starting point for the problem here, nice as LLVM is for what it does do well.
- comex 12y ago
  That didn't stop PNaCl. (Which has its share of problems, of course, but I think it makes the hardware dependence meme pretty moot.)
12y ago

hrktb 12y ago

There was a talk by Matz about ruby 2 and how they were tweaking the runtime to improve garbage collection. I don't remember the details but a lot of work went into seeking the best collection behavior to match the language, optimizing for the most common cases, checking the patterns favored by the language and tweaking the behavior to ease these cases, etc. The intersting thing is that there's jruby for the JVM, and it makes the different tradeoffs surface better. Looking at this benchmark for instance [0] it's easy to see how the tweaked runtime gives a very different performance profile from the generic VM. I have a feeling the highish-level intermediate layer you are talking about would be equivalent to have only some specific tradeoffs despite the optimizations that could be done on a language per language basis. [0]http://benchmarksgame.alioth.debian.org/u64q/jruby.php http://benchmarksgame.alioth.debian.org/u64q/jruby.php