18 ms·

Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

138 points by mbrubeck 15y ago

georgemcbay 15y ago
I feel for Brendan Eich, he is a bit of an unsung hero when you consider what he enabled with JavaScript and it is always stressful to learn someone is trying to kill your baby. Having said that, I really do hope it is killed. Well, not killed, but demoted to "one supported language of many". And the sooner this is started, the better, because it is a long, long process. I don't think JavaScript is bad, but I do strongly feel that the underlying engine for client side web programming should be a full-blown VM that supports many possible source languages (ala modern .net with the CLR, DLR and all), and I'll support that model regardless of who pushes it, so long as they do a good job on the technical side and don't try to use it as a lock-in mechanism. Google seems to be the most posed to do this (I can't imagine Microsoft giving up that much control of .net) and their idea to support JavaScript as an interim target is the only practical way this will ever be solved, so I hope Dart is successful -- assuming it is actually going for this and not just trying to switch one core language out with another, which remains to be seen when they announce more information. BTW, yes, I know you can already compile many other languages to JavaScript (as Dart itself will do in the first stage), but.. why? Why not just put a proper VM down there that is truly designed to efficiently run byte-code from many different source languages, and have JavaScript be one of those languages?
- thepumpkin1979 15y ago
  A standard VM/Runtime specification for all the browser would be awesome. We got plenty of them; CLR, DLR, JVM, Parrot, etc. Can you imagine? I can see those mime types already: application/csharp, application/perl, application/ruby, application/IL.
  - StrawberryFrog 15y ago
    To be pedantic, it wouldn't be "application/csharp". By the time it's compiled to MSIL bytecode it doesn't matter if it was C#, VB, F# or whatever. "application/MSIL" is what I'd say. I can imagine it, and I guess my browsers already have three VM/Runtimes in them (JavaScript, Flash, Silverlight) but it feels so inelegantly top-heavy to have lots more.
    - thepumpkin1979 15y ago
      Right, call me silly but I'm honoring the "Right-click->View Source" spirit here, I don't know about you but I feel more confortable knowing that my browser is downloading source code and compiling or interpreting than downloading some kind of binary to execute, even if you call it "intermediate code", "byte code" "almost-there-machine-code" or whatever, it's still binary stuff. I get your point though.
      - StrawberryFrog 15y ago
        I agree, source is better. But. Flash isn't served as source, is it? And JS is often minified/obfuscated. Sure you can run that through a tool to get back the source (sans comments and long variable names) but you can do just that with MSIL bytecode too.
        thepumpkin1979 15y ago
        Yep, Agree. Then we will see how additional tabs emerge in Firebug and Chrome Developer Tools, I can see them already: "IL View", ".NET Refactor", "JSIL View" hehe.
  - SwellJoe 15y ago
    This was the original intent (to have many languages supported by browsers; not necessarily a single VM with many languages). It just never really materialized. By the time the web was ready for bigger apps that needed more software, Javascript was Good Enough for the purpose, and munging other languages into the browser was too much effort. JavaScript grew up alongside HTML and the DOM, making it uniquely qualified for building applications around HTML and the DOM. I think it's telling that Google is building a new language rather than modifying an existing one (though it does appear to be inspired by other languages).
    - BrendanEich 15y ago
      I agree with your conclusions, especially that it's telling what Google is not doing, but I have to object to your "This was the original intent" lede. Whose intent was that? Not Sun's in '95 or '96 with the JVM, which was all about Java. Certainly not Netscape's. Multi-VM/multi-language beats multi-language-single-VM, indeed, but then you have problems such as the cross-heap cycle collection one I raised on this thread. No free lunch. And anyway multi-language-single-VM was never any browser vendor's original intent. I had folks like John Ousterhout belatedly (early '96) pitching TCL, but smart enough to see that it wouldn't fly (John then tried pitching Tk for cross-platform widgets, but Netscape was already screwing up its platform -- no sale). Mid-90s C-Python, TCL, Perl 4 then 5 -- none of these was ever intended to be wedged into any browser and kept up-to-date. Not by Netscape or Microsoft or any vendor of that era, and not in the 2000s either. MS put IE on skeleton crew maintenance. The Silverlight-era "DLR" (single VM for many languages) was much later and not browser-bound.
      - SwellJoe 15y ago
        "Whose intent was that?" I have no idea. But, the script tag in HTML, for example, allows specification of language (i.e. "<script type="text/javascript">, historically). It was my understanding that this was intended to permit other languages to be included in the browser, or as plugins. It was used by Microsoft for vbscript, and others along the way. I thought that was the intent of that flexibility built into HTML. And, I noted that it was not intended for a multi-language VM ("not necessarily a single VM with many languages", to quote myself, which I guess could have been more emphatic in denying that a multi-language VM was intended; I sort of assumed everyone would consider multi-language VMs the new hotness and not something that would have been considered back in the early days of VM-based languages becoming mainstream). I merely meant that other languages were supposed to be possible. Which makes sense. No one knew (maybe you had a gut feeling), with any confidence that JavaScript would grow up to be as capable as it has. And, the idea of a multi-language multi-paradigm VM is pretty novel stuff even now. Only in the past ten years or so have we started to see people building disparate languages on a single VM and others building VMs for the purpose of hosting widely varying languages. And, those experiments are still up in the air, as far as I can tell. The JVM does pretty well for Java-like languages, and Parrot can run dynamic languages, and LLVM is great for C/C++ and their descendants...but, push them out of their comfort zone and things get hairier and the VM probably needs to grow bigger and more like the language it is hosting. They'll probably work it all out eventually. But, I certainly don't think multi-language VMs were on the minds of the creators of HTML or the browser makers. I'm not sure we disagree (and I would obviously have to defer to your much greater knowledge on the subject, even if we did disagree). I could have been more clear in what I was suggesting was "the original intent".
- DanielRibeiro 15y ago
  Google's PNaCl is trying to promote this. I've talked about this a few weeks ago[1]. But until it gets widely deployed and accepted, it is just yet another standard[2] that will unify everything. [1] http://bit.ly/phxe16 http://bit.ly/phxe16 [2] http://xkcd.com/927/ http://xkcd.com/927/
  - azakai 15y ago
    It's not even another standard - it's an experimental implementation.
- LeafStorm 15y ago
  The main problem with common VMs for multiple existing languages is that often the semantics of the language are heavily coded into the VM. For example, Parrot's core opcodes mimic Perl's behavior of "Type coercion for everyone, the string "0" is false!" There are a lot of other issues as well, and while they are certainly solvable, the resulting VM would be very heavyweight. If you want to design a VM that runs multiple languages, often you have to design the languages around the VM.
  - chromatic 15y ago
    Parrot's core opcodes mimic Perl's behavior of "Type coercion for everyone, the string "0" is false!" That's true only for the intrinsic STRING type. Language-specific strings supply their own boolean semantics.
    - adgar 15y ago
      But then if the VM optimizes code paths related to STRING operations, languages can't take advantage of them as easily. There's a reason why the fastest VMs are deeply tied to the semantics of the language they support, LuaJIT being the best example.
      - chromatic 15y ago
        You're right about LuaJIT, but there's no reason the VM can't also optimize code paths related to high-level string operations.
        Nitramp 15y ago
        Well, at some point you might run out of space in the opcode byte (or multiple bytes), and then you need longer sequences that put up more cache pressure and require more time decoding, right? Also, the developers time budget and the VMs complexity migth keep you from optimizing all possible paths.
- mbrubeck 15y ago
  Brendan has previously talked about some obstacles to a bytecode/VM-level specification, and some advantages of specifying the browser language at the source level rather than at the bytecode level: http://news.ycombinator.com/item?id=1893686 http://news.ycombinator.com/item?id=1893686 (see comments by BrendanEich and others) http://www.aminutewithbrendan.com/pages/20101122 http://www.aminutewithbrendan.com/pages/20101122 http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebPart2MadnessOrJustInsanity.aspx http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageFo...
- _sh 15y ago
  The reason you won't see a bytecode VM replace Javascript is because bytecode is either interpreted (slow) or JIT-compiled (complicated but faster). If you go for speed and JIT-compile bytecode, why not just compile your source and dispense with bytecodes altogether (as V8 has done)? This gives other runtime implementers the freedom to choose whether to create an interpreter, compiler, or some other execution mechanism, and the programmers the freedom to code at a high-level. Bytecode, as distinct from object code, is on the way out. Consider Javascript a portable high-level object code and move on. If you want other languages, compile them to Javascript. Semantic affinity between source language and execution environment (e.g. is "0" false, as mentioned elsewhere) is an issue you'll need to address regardless of whether you're using bytecode. Also, don't underestimate the power 'view source' had in making Javascript perhaps one of the most widely-adopted programming languages in the world.
  - jeske 15y ago
    The trouble with this approach is that the Javascript prototype-based object model is somewhat incompatibile with precompiled-library loading. Loading Javascript (Even in bytecode form) requires running the code. Modern desktop/server software leverages tons of code via shared-libraries with fast startup times, but Javascript webpages have horrible startup times with only tiny amounts of library code. This problem is important to fix or the javascript ecosystem will be prevented from effectively building higher and higher leverage software layers. In addition, Javascript's abstractions are based on relatively slow mechanisms such as dynamic-hashes. This make it difficult if not impossible to get C/Java/C# like performance out of it even with a JIT. You can build fast dynamic hashes out of structs, but you can't really build fast structs out of dynamic hashes.
    - BrendanEich 15y ago
      Evaluating function declarations and expressions, even in a module pattern closure, takes well under a millisecond in modern browsers. The "dynamic-hashes" remark shows serious ignorance of polymorphic inline caches and shapes aka hidden classes. Competitive JS JITs do not probe hashtables for dot member accesses.
equark 15y ago
From what is known, it seems as if Google plans to move all their Javascript app building efforts to Dart. Given that GWT/Closure are already pretty successful in large organizations and internally, that seems like a big bet on Dart's future. Whether the Dart VM gets adopted by other browsers seems relatively inconsequential provided they have a decent cross-compilation story. Assume Dart is objectively better except for lacking browser support. Even Brendan Eich seems to admit that Dart will be "better". Then developing using Dart will give you an adult tooling story (through Chrome/Dash VM/Brightly), a server-side front-end language (capable of Google-scale applications), optimized compilation to Javascript (presumably better than GWT), and major corporate backing (in contrast to coffeescript). This seems to be like the makings for a major win provided that Google commits to adopting it internally.
- wavephorm 15y ago
  Google is clearly priming to do a Microsoft-style embrace-and-extend in a big way. Between Chrome, V8, NaCL, WebGL, Android, they have a wide range of technologies that they could begin steering away from standards.
  - ender7 15y ago
    But...why? Google makes money selling ads. It doesn't make money selling you support contracts for software that you've been locked into. From what I can tell, Android exists so that Google isn't at the whim of Apple. The big G's greatest fear is that iPhones become the defacto smartphone, and Apple has the power to cut them out of their platform (by banning Google's ad networks and by setting the default search engine to Bing). I doubt the Android platform will ever really make money for Google.
    - wavephorm 15y ago
      Google's strategy may be different than Microsoft, but the motivation is the same: to trap developers, and make them dependent on you, and to differentiate their technology from their peers.
    - 15y ago
danmaz74 15y ago
I'm afraid it's already too late to make suggestions, but I would be really excited if Dart supported facilities to make unit testing an integral part of the language, taking into consideration the interaction with the DOM. This is something that would really help IMHO.
- kmmbvnr 15y ago
  Google's Go have unit testing in build-in libraries. Hope Dart developers will not forget about testing also.
- bzbarsky 15y ago
  > I'm afraid it's already too late to make suggestions, Which was precisely the point of developing things this way. They don't want anyone's suggestions; they want to force the thing that benefits _them_ the most on everyone else.
rafaelferreira 15y ago
It is probably true that, even with a cross-compilation strategy, if Dart doesn't get adopted by competing browser vendors it will be a force towards fragmentation, which tends to be bad for the web. An interesting question to consider, IMO, is whether a "clean break" for client programming languages is a bad idea outright, irrespective of context and motivation. If it is, it follows that the principal means for information dissemination and collaboration our species has devised will forever be programmed in the same language. It is a bleak thought, because, even if the language was faultless at its time, progress happens and the web needs to improve. Of course Javascript can evolve (I personally very much like the proposals, and look forward to working with ES.next), but any language designer knows once some decisions are made there is no way to go back and revisit them. If we allow for the possibility of a "clean break", then we can ask ourselves how could it be done. IMHO, committees don't fare all that well in language design. I think it would have to come from a single knowledgeable designer or a group of closely aligned knowledgeable designers. I also think it would be impossible to evaluate such a language without a real implementation. A real implementation would have to be in a real browser. So, a Browser vendor that employs experienced language designers seems like a good candidate to try a clean break, and I'd be glad if it succeeds.
- BrendanEich 15y ago
  Thumbnail of possible future (first is happening): ES6: modules and shallow continuations; ES7: guards, contracts, event loop concurrency; ES8: macros, parallel arrays (SIMD). JS evolution disrupts the clean-break rationale. Languages can change both surface and semantics. The open question I see is: can JS become the VM (its source the "bytecode") to host many languages and several approaches (none memory unsafe; no shared-memory threads). We have lots of evidence for JS becoming the VM already, along with nay-sayers who want a clean break. I'm going with evidence over clean-break assertions until we hit a wall that is either inherent in the language or emergent in the standards body and the market. Again, this is why I am concerned about Google playing fair.
ricardobeat 15y ago
Classes :(
adgar 15y ago
I hate to say it, because Brendan Eich is no blogspammer, but I feel like he name-dropped Google Dart (Dash) as well-intentioned linkbait. It's mentioned in one sentence and offers no new details or interesting discussion. I agree with georgemcbay that he has reason to be disturbed by Dart's appearance and the backing of Google/Chrome, but with no actual details, he's just taking a quick shot at it while he can here.
- BrendanEich 15y ago
  I took no shot at Dart because we all know nearly nothing about it. My whole talk was about how competing browser vendors work together to standardize and evolve JS. In that light, bailing to a proprietary move like Dart is entirely relevant and not linkbait. This is a non-technical, or really meta-technical point. Lots of JS and web standards work is about techniques for solving technical problems, hence meta. Any well-funded company with smart people on staff can "do better" for a given point-function or language in the set of languages. On the web, such better-is-better approaches won't get traction without being adopted by multiple competing browsers. The best way to get adoption is standardization. Forcing reverse-engineering, open-washing as if that helps competing vendors more than a little (assuming their hackers can even read the delayed-open source as a reference), fragmenting web content are all "less good" in my view. A browser with market power can try these tactics. They may backfire, or make a messy "now you have two problems" world.
deleted 15y ago
[deleted]
gruseom 15y ago
I'll pipe up with one thing nobody seems to be emphasizing. A lot depends on how good Dart turns out to be. Suppose it turns out so good that we get all four of the following: 1. No worse a user experience in any browser; 2. A much better user experience in Chrome; 3. A much better developer experience; 4. A much better server-side platform than V8. If we get all that, standards or not, I will be jumping for joy. If Dart is that good, it will become standard, either de jure or de facto as alternatives fall by the wayside. Of the four, #1 (a good enough Dart->JS) seems problematic. #2 may be bad for other browser vendors, but if it's good for users and programmers, why should I care? I see no virtue in a lowest common denominator. #3 and #4 are hardly objectionable. Only those who like them need bother. I don't know how likely this win-win-win-win is, but here's why I'm indulging in the hope. These guys have been gods of fast dynamic VMs since Strongtalk. If Dart is their chance to build what they always wanted, but this time with 20 years of experience to draw on and the institutional support of a Google behind them... well, we have the chance of something insanely great. Greatness sets its own standard. Comparisons to VBScript and Flash only kick in if what they come out with is lacklustre.
- BrendanEich 15y ago
  The comparison to VBScript is not technical at all. It is about single-vendor control. Your item 1 is obviously problematic. If Dart and JS have close semantics, it's just a transpiler like CoffeeScript, which intentionally sugars JS semantics with leaner syntax. But this does not match the leaked info and hype about Dart, and even then, such warm beer still requires you to run a tool over your primary source, which costs adoption. Lots of languages already contending in this transpiling space. More likely, a Dart-to-JS compiler (making non-local transformations) and a JS-implemented Dart runtime (to support the novel runtime semantics, e.g. new numeric types) will be required. This means a worse user experience in browsers that don't have the native Dart VM, because performance will lag (especially depending on the new numeric type details) and bug-for-bug compatibility will be lost. The native VM will be the super-fast source of truth. The compiler/runtime will be a stop-gap. This brings us back to the standards table, unless the idea is to corner the browser market. See https://news.ycombinator.com/item?id=2983157 https://news.ycombinator.com/item?id=2983157 under "On Dart: ..." about what the standards table would look like if it is anywhere near today's mix of browser vendors and other interested parties.
ryanisinallofus 15y ago
"his is why I think cooperating in standards bodies is critical for web interop and non-fragmentation. It necessarily implies less competitive content languages at any given instant, but with consequent widest reach." I think it's interesting he's admitting to standards bodies leading to inferior languages but that the benefits include wide reach. I disagree. See HttpRequest. I say let the browsers innovate at will and let the standards bodies come in and standardize what people are actually using after the fact. Shoot first, ask standards bodies later.
- BrendanEich 15y ago
  "... he's admitting ..."? Hello, I'm here, and you're not deposing me, so drop the lawyer talk. Also, try to pay attention to the historical correlation of market forces: XHR came in when Microsoft was a monopoly: http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_support http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_supp... Even then, it was new and optional, and we cloned it into Mozilla (Opera cloned it too). It was pretty simple compared to anything like Dart or NaCl's Pepper APIs. Ok, look where we are today: no monopoly power, but Google arguably acting like one. That won't lead to reverse-engineering without a much less balanced market. First, the reverse-engineering costs of Dart are much higher than of XHR. Second, the more balanced competition won't make any browser follow instead of lead. We could indeed end up with two problems (three, counting JS), as just happened with WebSQL and IndexedDB. Dart, and Microsoft's new language Phart, say. :-P Glib "shoot first, ask standards bodies later" is a recipe for fragmentation and non-interoperation. Even if standards are written (years later, for XHR; never for VBScript and ActiveX and a great many examples you conveniently ignore), they don't offset the up front costs. And here's the kicker: if you get your wish, there won't be one interoperable superior language ruling the roost until that later standardization step, if it even happens. If there's no monopoly or duopoly power structure, you'll just have the "inferior" language (JS) and spotty support for the "superior" one. It seems to me that a lot of you "bring on our new overlords" boosters are unaware of how HTML5 came about. It was not through one vendor shipping proprietary code and standards bodies mopping up later. Study some recent history.
  - ryanisinallofus 15y ago
KamilTrebunia 15y ago
Dart will not be 2x (or more) faster than JS. Dart will not be so much more expressive and elegant than JS is. Google would have to replace the whole stack (from HTTP to DOM to Dart to IDEs) to make it really compelling, but I'm pretty sure they will give it a shot. Fortunately there is a competition: Nobody will dedicate himself to Chrome Web Store and Google Web technologies and miss out on future Facebook WebApp Store (or whatever Project Spartan turns out to be) or future Apple AppStore (I believe in Apple's intelligence and visionary and that they will realize potential of Open Web and Clouds in time). Android also is in trouble so unless Google will win the mobile market big time it will get more fragmented and thus forcing everybody to jump into Open Web and not Google Web. And then there's Mozilla - let's hope they can pull off some good piece technology with their B2G and Firefox Mobile! At least that's what I want to believe...
- equark 15y ago
  > Dart will not be 2x (or more) faster than JS. Why are you so sure of this? The people involved appear to be big believers that dynamic languages can be extremely performant provided they are designed with the VM in mind. LuaJit proves this out. A simple 1000x1000 matrix multiply in LuaJit is already 20x (not 2x!) faster than V8 and on par with C. http://attractivechaos.wordpress.com/2011/01/23/amazed-by-luajit/ http://attractivechaos.wordpress.com/2011/01/23/amazed-by-lu... http://lua-users.org/lists/lua-l/2009-06/msg00071.html http://lua-users.org/lists/lua-l/2009-06/msg00071.html I think far too much emphasis is being placed on whether Dart replaces JS in the browser. Google would gain a huge amount by having a performant server-side language that can be tooled and compiled to JS for the client.
  - mraleph 15y ago
    > A simple 1000x1000 matrix multiply in LuaJit is already 20x (not 2x!) faster than V8 and on par with C. You are using outdated measurements. Up to date results: http://attractivechaos.github.com/plb/plb-lang.png http://attractivechaos.github.com/plb/plb-lang.png http://attractivechaos.github.com/plb/ http://attractivechaos.github.com/plb/ The difference between V8 and LuaJIT is nowhere near 2x on matmul and comes from differences in language features (no debugger interruption support for generated code in LuaJIT2) and lack of certain optimizations (e.g. array bounds check elimination) in V8 [matmul_v2.lua used for measurements relies on ffi arrays which do not include bounds checks at all]. Code generated by both compilers is roughly equivalent (invariants hosted out of the loop, temporary double values are on xmm registers, etc). A bit more details: http://blog.mrale.ph/post/5436474765/dangers-of-cross-language-benchmark-games http://blog.mrale.ph/post/5436474765/dangers-of-cross-langua...

138 points by mbrubeck 15y ago

I feel for Brendan Eich, he is a bit of an unsung hero when you consider what he enabled with JavaScript and it is always stressful to learn someone is trying to kill your baby. Having said that, I really do hope it is killed. Well, not killed, but demoted to "one supported language of many". And the sooner this is started, the better, because it is a long, long process. I don't think JavaScript is bad, but I do strongly feel that the underlying engine for client side web programming should be a full-blown VM that supports many possible source languages (ala modern .net with the CLR, DLR and all), and I'll support that model regardless of who pushes it, so long as they do a good job on the technical side and don't try to use it as a lock-in mechanism. Google seems to be the most posed to do this (I can't imagine Microsoft giving up that much control of .net) and their idea to support JavaScript as an interim target is the only practical way this will ever be solved, so I hope Dart is successful -- assuming it is actually going for this and not just trying to switch one core language out with another, which remains to be seen when they announce more information. BTW, yes, I know you can already compile many other languages to JavaScript (as Dart itself will do in the first stage), but.. why? Why not just put a proper VM down there that is truly designed to efficiently run byte-code from many different source languages, and have JavaScript be one of those languages?

thepumpkin1979 15y ago
A standard VM/Runtime specification for all the browser would be awesome. We got plenty of them; CLR, DLR, JVM, Parrot, etc. Can you imagine? I can see those mime types already: application/csharp, application/perl, application/ruby, application/IL.
- StrawberryFrog 15y ago
  To be pedantic, it wouldn't be "application/csharp". By the time it's compiled to MSIL bytecode it doesn't matter if it was C#, VB, F# or whatever. "application/MSIL" is what I'd say. I can imagine it, and I guess my browsers already have three VM/Runtimes in them (JavaScript, Flash, Silverlight) but it feels so inelegantly top-heavy to have lots more.
  - thepumpkin1979 15y ago
    Right, call me silly but I'm honoring the "Right-click->View Source" spirit here, I don't know about you but I feel more confortable knowing that my browser is downloading source code and compiling or interpreting than downloading some kind of binary to execute, even if you call it "intermediate code", "byte code" "almost-there-machine-code" or whatever, it's still binary stuff. I get your point though.
    - StrawberryFrog 15y ago
      I agree, source is better. But. Flash isn't served as source, is it? And JS is often minified/obfuscated. Sure you can run that through a tool to get back the source (sans comments and long variable names) but you can do just that with MSIL bytecode too.
      - thepumpkin1979 15y ago
        Yep, Agree. Then we will see how additional tabs emerge in Firebug and Chrome Developer Tools, I can see them already: "IL View", ".NET Refactor", "JSIL View" hehe.
- SwellJoe 15y ago
  This was the original intent (to have many languages supported by browsers; not necessarily a single VM with many languages). It just never really materialized. By the time the web was ready for bigger apps that needed more software, Javascript was Good Enough for the purpose, and munging other languages into the browser was too much effort. JavaScript grew up alongside HTML and the DOM, making it uniquely qualified for building applications around HTML and the DOM. I think it's telling that Google is building a new language rather than modifying an existing one (though it does appear to be inspired by other languages).
  - BrendanEich 15y ago
    I agree with your conclusions, especially that it's telling what Google is not doing, but I have to object to your "This was the original intent" lede. Whose intent was that? Not Sun's in '95 or '96 with the JVM, which was all about Java. Certainly not Netscape's. Multi-VM/multi-language beats multi-language-single-VM, indeed, but then you have problems such as the cross-heap cycle collection one I raised on this thread. No free lunch. And anyway multi-language-single-VM was never any browser vendor's original intent. I had folks like John Ousterhout belatedly (early '96) pitching TCL, but smart enough to see that it wouldn't fly (John then tried pitching Tk for cross-platform widgets, but Netscape was already screwing up its platform -- no sale). Mid-90s C-Python, TCL, Perl 4 then 5 -- none of these was ever intended to be wedged into any browser and kept up-to-date. Not by Netscape or Microsoft or any vendor of that era, and not in the 2000s either. MS put IE on skeleton crew maintenance. The Silverlight-era "DLR" (single VM for many languages) was much later and not browser-bound.
    - SwellJoe 15y ago
      "Whose intent was that?" I have no idea. But, the script tag in HTML, for example, allows specification of language (i.e. "<script type="text/javascript">, historically). It was my understanding that this was intended to permit other languages to be included in the browser, or as plugins. It was used by Microsoft for vbscript, and others along the way. I thought that was the intent of that flexibility built into HTML. And, I noted that it was not intended for a multi-language VM ("not necessarily a single VM with many languages", to quote myself, which I guess could have been more emphatic in denying that a multi-language VM was intended; I sort of assumed everyone would consider multi-language VMs the new hotness and not something that would have been considered back in the early days of VM-based languages becoming mainstream). I merely meant that other languages were supposed to be possible. Which makes sense. No one knew (maybe you had a gut feeling), with any confidence that JavaScript would grow up to be as capable as it has. And, the idea of a multi-language multi-paradigm VM is pretty novel stuff even now. Only in the past ten years or so have we started to see people building disparate languages on a single VM and others building VMs for the purpose of hosting widely varying languages. And, those experiments are still up in the air, as far as I can tell. The JVM does pretty well for Java-like languages, and Parrot can run dynamic languages, and LLVM is great for C/C++ and their descendants...but, push them out of their comfort zone and things get hairier and the VM probably needs to grow bigger and more like the language it is hosting. They'll probably work it all out eventually. But, I certainly don't think multi-language VMs were on the minds of the creators of HTML or the browser makers. I'm not sure we disagree (and I would obviously have to defer to your much greater knowledge on the subject, even if we did disagree). I could have been more clear in what I was suggesting was "the original intent".
DanielRibeiro 15y ago
Google's PNaCl is trying to promote this. I've talked about this a few weeks ago[1]. But until it gets widely deployed and accepted, it is just yet another standard[2] that will unify everything. [1] http://bit.ly/phxe16 http://bit.ly/phxe16 [2] http://xkcd.com/927/ http://xkcd.com/927/
- azakai 15y ago
  It's not even another standard - it's an experimental implementation.
LeafStorm 15y ago
The main problem with common VMs for multiple existing languages is that often the semantics of the language are heavily coded into the VM. For example, Parrot's core opcodes mimic Perl's behavior of "Type coercion for everyone, the string "0" is false!" There are a lot of other issues as well, and while they are certainly solvable, the resulting VM would be very heavyweight. If you want to design a VM that runs multiple languages, often you have to design the languages around the VM.
- chromatic 15y ago
  Parrot's core opcodes mimic Perl's behavior of "Type coercion for everyone, the string "0" is false!" That's true only for the intrinsic STRING type. Language-specific strings supply their own boolean semantics.
  - adgar 15y ago
    But then if the VM optimizes code paths related to STRING operations, languages can't take advantage of them as easily. There's a reason why the fastest VMs are deeply tied to the semantics of the language they support, LuaJIT being the best example.
    - chromatic 15y ago
      You're right about LuaJIT, but there's no reason the VM can't also optimize code paths related to high-level string operations.
      - Nitramp 15y ago
        Well, at some point you might run out of space in the opcode byte (or multiple bytes), and then you need longer sequences that put up more cache pressure and require more time decoding, right? Also, the developers time budget and the VMs complexity migth keep you from optimizing all possible paths.
mbrubeck 15y ago
Brendan has previously talked about some obstacles to a bytecode/VM-level specification, and some advantages of specifying the browser language at the source level rather than at the bytecode level: http://news.ycombinator.com/item?id=1893686 http://news.ycombinator.com/item?id=1893686 (see comments by BrendanEich and others) http://www.aminutewithbrendan.com/pages/20101122 http://www.aminutewithbrendan.com/pages/20101122 http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebPart2MadnessOrJustInsanity.aspx http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageFo...
_sh 15y ago
The reason you won't see a bytecode VM replace Javascript is because bytecode is either interpreted (slow) or JIT-compiled (complicated but faster). If you go for speed and JIT-compile bytecode, why not just compile your source and dispense with bytecodes altogether (as V8 has done)? This gives other runtime implementers the freedom to choose whether to create an interpreter, compiler, or some other execution mechanism, and the programmers the freedom to code at a high-level. Bytecode, as distinct from object code, is on the way out. Consider Javascript a portable high-level object code and move on. If you want other languages, compile them to Javascript. Semantic affinity between source language and execution environment (e.g. is "0" false, as mentioned elsewhere) is an issue you'll need to address regardless of whether you're using bytecode. Also, don't underestimate the power 'view source' had in making Javascript perhaps one of the most widely-adopted programming languages in the world.
- jeske 15y ago
  The trouble with this approach is that the Javascript prototype-based object model is somewhat incompatibile with precompiled-library loading. Loading Javascript (Even in bytecode form) requires running the code. Modern desktop/server software leverages tons of code via shared-libraries with fast startup times, but Javascript webpages have horrible startup times with only tiny amounts of library code. This problem is important to fix or the javascript ecosystem will be prevented from effectively building higher and higher leverage software layers. In addition, Javascript's abstractions are based on relatively slow mechanisms such as dynamic-hashes. This make it difficult if not impossible to get C/Java/C# like performance out of it even with a JIT. You can build fast dynamic hashes out of structs, but you can't really build fast structs out of dynamic hashes.
  - BrendanEich 15y ago
    Evaluating function declarations and expressions, even in a module pattern closure, takes well under a millisecond in modern browsers. The "dynamic-hashes" remark shows serious ignorance of polymorphic inline caches and shapes aka hidden classes. Competitive JS JITs do not probe hashtables for dot member accesses.

equark 15y ago

From what is known, it seems as if Google plans to move all their Javascript app building efforts to Dart. Given that GWT/Closure are already pretty successful in large organizations and internally, that seems like a big bet on Dart's future. Whether the Dart VM gets adopted by other browsers seems relatively inconsequential provided they have a decent cross-compilation story. Assume Dart is objectively better except for lacking browser support. Even Brendan Eich seems to admit that Dart will be "better". Then developing using Dart will give you an adult tooling story (through Chrome/Dash VM/Brightly), a server-side front-end language (capable of Google-scale applications), optimized compilation to Javascript (presumably better than GWT), and major corporate backing (in contrast to coffeescript). This seems to be like the makings for a major win provided that Google commits to adopting it internally.

wavephorm 15y ago
Google is clearly priming to do a Microsoft-style embrace-and-extend in a big way. Between Chrome, V8, NaCL, WebGL, Android, they have a wide range of technologies that they could begin steering away from standards.
- ender7 15y ago
  But...why? Google makes money selling ads. It doesn't make money selling you support contracts for software that you've been locked into. From what I can tell, Android exists so that Google isn't at the whim of Apple. The big G's greatest fear is that iPhones become the defacto smartphone, and Apple has the power to cut them out of their platform (by banning Google's ad networks and by setting the default search engine to Bing). I doubt the Android platform will ever really make money for Google.
  - wavephorm 15y ago
    Google's strategy may be different than Microsoft, but the motivation is the same: to trap developers, and make them dependent on you, and to differentiate their technology from their peers.
  - 15y ago

danmaz74 15y ago

I'm afraid it's already too late to make suggestions, but I would be really excited if Dart supported facilities to make unit testing an integral part of the language, taking into consideration the interaction with the DOM. This is something that would really help IMHO.

kmmbvnr 15y ago
Google's Go have unit testing in build-in libraries. Hope Dart developers will not forget about testing also.
bzbarsky 15y ago
> I'm afraid it's already too late to make suggestions, Which was precisely the point of developing things this way. They don't want anyone's suggestions; they want to force the thing that benefits _them_ the most on everyone else.

rafaelferreira 15y ago

It is probably true that, even with a cross-compilation strategy, if Dart doesn't get adopted by competing browser vendors it will be a force towards fragmentation, which tends to be bad for the web. An interesting question to consider, IMO, is whether a "clean break" for client programming languages is a bad idea outright, irrespective of context and motivation. If it is, it follows that the principal means for information dissemination and collaboration our species has devised will forever be programmed in the same language. It is a bleak thought, because, even if the language was faultless at its time, progress happens and the web needs to improve. Of course Javascript can evolve (I personally very much like the proposals, and look forward to working with ES.next), but any language designer knows once some decisions are made there is no way to go back and revisit them. If we allow for the possibility of a "clean break", then we can ask ourselves how could it be done. IMHO, committees don't fare all that well in language design. I think it would have to come from a single knowledgeable designer or a group of closely aligned knowledgeable designers. I also think it would be impossible to evaluate such a language without a real implementation. A real implementation would have to be in a real browser. So, a Browser vendor that employs experienced language designers seems like a good candidate to try a clean break, and I'd be glad if it succeeds.

BrendanEich 15y ago
Thumbnail of possible future (first is happening): ES6: modules and shallow continuations; ES7: guards, contracts, event loop concurrency; ES8: macros, parallel arrays (SIMD). JS evolution disrupts the clean-break rationale. Languages can change both surface and semantics. The open question I see is: can JS become the VM (its source the "bytecode") to host many languages and several approaches (none memory unsafe; no shared-memory threads). We have lots of evidence for JS becoming the VM already, along with nay-sayers who want a clean break. I'm going with evidence over clean-break assertions until we hit a wall that is either inherent in the language or emergent in the standards body and the market. Again, this is why I am concerned about Google playing fair.

ricardobeat 15y ago

Classes :(

adgar 15y ago

I hate to say it, because Brendan Eich is no blogspammer, but I feel like he name-dropped Google Dart (Dash) as well-intentioned linkbait. It's mentioned in one sentence and offers no new details or interesting discussion. I agree with georgemcbay that he has reason to be disturbed by Dart's appearance and the backing of Google/Chrome, but with no actual details, he's just taking a quick shot at it while he can here.

BrendanEich 15y ago
I took no shot at Dart because we all know nearly nothing about it. My whole talk was about how competing browser vendors work together to standardize and evolve JS. In that light, bailing to a proprietary move like Dart is entirely relevant and not linkbait. This is a non-technical, or really meta-technical point. Lots of JS and web standards work is about techniques for solving technical problems, hence meta. Any well-funded company with smart people on staff can "do better" for a given point-function or language in the set of languages. On the web, such better-is-better approaches won't get traction without being adopted by multiple competing browsers. The best way to get adoption is standardization. Forcing reverse-engineering, open-washing as if that helps competing vendors more than a little (assuming their hackers can even read the delayed-open source as a reference), fragmenting web content are all "less good" in my view. A browser with market power can try these tactics. They may backfire, or make a messy "now you have two problems" world.

deleted 15y ago

[deleted]

gruseom 15y ago

I'll pipe up with one thing nobody seems to be emphasizing. A lot depends on how good Dart turns out to be. Suppose it turns out so good that we get all four of the following: 1. No worse a user experience in any browser; 2. A much better user experience in Chrome; 3. A much better developer experience; 4. A much better server-side platform than V8. If we get all that, standards or not, I will be jumping for joy. If Dart is that good, it will become standard, either de jure or de facto as alternatives fall by the wayside. Of the four, #1 (a good enough Dart->JS) seems problematic. #2 may be bad for other browser vendors, but if it's good for users and programmers, why should I care? I see no virtue in a lowest common denominator. #3 and #4 are hardly objectionable. Only those who like them need bother. I don't know how likely this win-win-win-win is, but here's why I'm indulging in the hope. These guys have been gods of fast dynamic VMs since Strongtalk. If Dart is their chance to build what they always wanted, but this time with 20 years of experience to draw on and the institutional support of a Google behind them... well, we have the chance of something insanely great. Greatness sets its own standard. Comparisons to VBScript and Flash only kick in if what they come out with is lacklustre.

BrendanEich 15y ago
The comparison to VBScript is not technical at all. It is about single-vendor control. Your item 1 is obviously problematic. If Dart and JS have close semantics, it's just a transpiler like CoffeeScript, which intentionally sugars JS semantics with leaner syntax. But this does not match the leaked info and hype about Dart, and even then, such warm beer still requires you to run a tool over your primary source, which costs adoption. Lots of languages already contending in this transpiling space. More likely, a Dart-to-JS compiler (making non-local transformations) and a JS-implemented Dart runtime (to support the novel runtime semantics, e.g. new numeric types) will be required. This means a worse user experience in browsers that don't have the native Dart VM, because performance will lag (especially depending on the new numeric type details) and bug-for-bug compatibility will be lost. The native VM will be the super-fast source of truth. The compiler/runtime will be a stop-gap. This brings us back to the standards table, unless the idea is to corner the browser market. See https://news.ycombinator.com/item?id=2983157 https://news.ycombinator.com/item?id=2983157 under "On Dart: ..." about what the standards table would look like if it is anywhere near today's mix of browser vendors and other interested parties.

ryanisinallofus 15y ago

"his is why I think cooperating in standards bodies is critical for web interop and non-fragmentation. It necessarily implies less competitive content languages at any given instant, but with consequent widest reach." I think it's interesting he's admitting to standards bodies leading to inferior languages but that the benefits include wide reach. I disagree. See HttpRequest. I say let the browsers innovate at will and let the standards bodies come in and standardize what people are actually using after the fact. Shoot first, ask standards bodies later.

BrendanEich 15y ago
"... he's admitting ..."? Hello, I'm here, and you're not deposing me, so drop the lawyer talk. Also, try to pay attention to the historical correlation of market forces: XHR came in when Microsoft was a monopoly: http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_support http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_supp... Even then, it was new and optional, and we cloned it into Mozilla (Opera cloned it too). It was pretty simple compared to anything like Dart or NaCl's Pepper APIs. Ok, look where we are today: no monopoly power, but Google arguably acting like one. That won't lead to reverse-engineering without a much less balanced market. First, the reverse-engineering costs of Dart are much higher than of XHR. Second, the more balanced competition won't make any browser follow instead of lead. We could indeed end up with two problems (three, counting JS), as just happened with WebSQL and IndexedDB. Dart, and Microsoft's new language Phart, say. :-P Glib "shoot first, ask standards bodies later" is a recipe for fragmentation and non-interoperation. Even if standards are written (years later, for XHR; never for VBScript and ActiveX and a great many examples you conveniently ignore), they don't offset the up front costs. And here's the kicker: if you get your wish, there won't be one interoperable superior language ruling the roost until that later standardization step, if it even happens. If there's no monopoly or duopoly power structure, you'll just have the "inferior" language (JS) and spotty support for the "superior" one. It seems to me that a lot of you "bring on our new overlords" boosters are unaware of how HTML5 came about. It was not through one vendor shipping proprietary code and standards bodies mopping up later. Study some recent history.
- ryanisinallofus 15y ago

KamilTrebunia 15y ago

Dart will not be 2x (or more) faster than JS. Dart will not be so much more expressive and elegant than JS is. Google would have to replace the whole stack (from HTTP to DOM to Dart to IDEs) to make it really compelling, but I'm pretty sure they will give it a shot. Fortunately there is a competition: Nobody will dedicate himself to Chrome Web Store and Google Web technologies and miss out on future Facebook WebApp Store (or whatever Project Spartan turns out to be) or future Apple AppStore (I believe in Apple's intelligence and visionary and that they will realize potential of Open Web and Clouds in time). Android also is in trouble so unless Google will win the mobile market big time it will get more fragmented and thus forcing everybody to jump into Open Web and not Google Web. And then there's Mozilla - let's hope they can pull off some good piece technology with their B2G and Firefox Mobile! At least that's what I want to believe...

equark 15y ago
> Dart will not be 2x (or more) faster than JS. Why are you so sure of this? The people involved appear to be big believers that dynamic languages can be extremely performant provided they are designed with the VM in mind. LuaJit proves this out. A simple 1000x1000 matrix multiply in LuaJit is already 20x (not 2x!) faster than V8 and on par with C. http://attractivechaos.wordpress.com/2011/01/23/amazed-by-luajit/ http://attractivechaos.wordpress.com/2011/01/23/amazed-by-lu... http://lua-users.org/lists/lua-l/2009-06/msg00071.html http://lua-users.org/lists/lua-l/2009-06/msg00071.html I think far too much emphasis is being placed on whether Dart replaces JS in the browser. Google would gain a huge amount by having a performant server-side language that can be tooled and compiled to JS for the client.
- mraleph 15y ago
  > A simple 1000x1000 matrix multiply in LuaJit is already 20x (not 2x!) faster than V8 and on par with C. You are using outdated measurements. Up to date results: http://attractivechaos.github.com/plb/plb-lang.png http://attractivechaos.github.com/plb/plb-lang.png http://attractivechaos.github.com/plb/ http://attractivechaos.github.com/plb/ The difference between V8 and LuaJIT is nowhere near 2x on matmul and comes from differences in language features (no debugger interruption support for generated code in LuaJIT2) and lack of certain optimizations (e.g. array bounds check elimination) in V8 [matmul_v2.lua used for measurements relies on ffi arrays which do not include bounds checks at all]. Code generated by both compilers is roughly equivalent (invariants hosted out of the loop, temporary double values are on xmm registers, etc). A bit more details: http://blog.mrale.ph/post/5436474765/dangers-of-cross-language-benchmark-games http://blog.mrale.ph/post/5436474765/dangers-of-cross-langua...