4 ms·

The Dart team is not a large team and not an arrogant team. Led by Lars Bak, they thought to try and make something that ran faster than JavaScript by doing awa

The Dart team is not a large team and not an arrogant team. Led by Lars Bak, they thought to try and make something that ran faster than JavaScript by doing away with 'monkey patching.' Lars and Kasper Lund took all their experience working with V8 to make something that avoided the bottlenecks. Gilad Bracha designed a good working language and it works without many "gotchas" along the way. It's a pleasure to use. The Google Chrome team was not enthusiastic about it even before Blink, as you correctly state, but what I was trying to say is that if the industry hadn't reacted so negatively to Dart because of some percieved ulterior motive by Google, the Chrome team may have been persuaded to put some more thought into it and make it happen. Lars Bak, Kaser Lund, Gilad Bracha and the rest of the team did something cool and don't get any props for it because they work for Google. Such is life. I recall Mozilla disliked it the most, which I assume was driven by you, the creator of JavaScript. Dart was never going to replace JavaScript you know, because even then they were saying that anything that can be written in JavaScript, will be written in JavaScript. JavaScript is unstoppable, but people should look at Dart for what it is, another tool in the toolkit.

BrendanEich 11y ago
tl;dr -- "Dart is good". A fine view, I agree on parts. Your words do nothing to address the very real technical problems that kept DartVM out of Chrome. Stop personalizing everything and study the link I cited.
- oso2k 11y ago
  It's hard not to personalize things like what Oliver Hunt said in [0], "The issue here isn't "can we make multiple vms live in webkit" it's "can we expose multiple languages to the web", to the former i say obviously as we already do, to the latter I say that we don't want to." The general tone Oliver had was akin to saying only little-endian machines should be supported on the Web. Not because of some technically proven deficiency in the idea of allowing big-endian machines, but because "we don't want to." I can only imagine if such logic had been applied to other parts of the Web. Technical problems always have a solution. [0] https://lists.webkit.org/pipermail/webkit-dev/2011-December/018806.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
  - BrendanEich 11y ago
    Oliver is not me, nor has he ever worked for Mozilla. But you are not the OP, so this is all just more mistargeted drive-by and taking-it-too-personally complaining. There are not multiple GC'ed VMs in Safari sharing the DOM, so I bet Oliver was talking about things like JSC as another way to script Apple stuff than Obj-C (now Swift). But that's not material to the DartVM/OilPan vs. Chrome issue.
- michaelwww 11y ago
  Why does the Java VM run in a browser but the Dart VM is too hard?
  - BrendanEich 11y ago
    Please read anything I've written on the topic over the years. Java runs as a plugin, like Flash. It has no deep DOM integration. Both Java and Flash have become security problems, so they're in various penalty boxes, beyond the plugin prison. Back in 1995, when I did JS in the shadow of Java, as a sidekick Robin-the-boy-hostage language, I did the primordial DOM too. Java was in only applets then -- pretty much the same as a plugin. We did connect JS and Java via LiveConnect, which led to the JRI (Warren Harris at Netscape), which led to the JNI. To solve the GC problem, the JRI user had to manage handles for global and local roots. This did not solve the inter-heap cycle problem, however. Netscape never implemented a cycle collector, but we did at Mozilla, based on [Bacon & Rajan, 2001]. It was required for C++ and JS cycle collection. Around that time, IE would still leak memory if you made a C++/JS cycle by capturing certain global object property references in closures. Their C++ side used COM reference counting, so once the cycle closed through JScript, there was no way to drop the cycle-internal refcount. Mozilla's C++/JS cycle collector was originally meant to handle C-Python too (and possibly other languages with full XPCOM/DOM access), since we had an optional integration of that engine, courtesy Mark Hammond of Active State. But both the C-Python integration and the polyglot support in the CC got ripped out. Browsers cannot afford overhead, even mostly-dead (but still hazardous in the 0day sense) code. (Updated to note that LiveConnect is long-gone too. Java is just a plugin.) I suspect you still have not read Filip Pizlo's post at that lists.webkit.org link I left, or the paper it references. Please take more time to study problems before casting aspersions!
    - michaelwww 11y ago
      What aspersions? I've noted your opposition to Dart. You've explained that it has to do with memory management difficulties that seem intractable. I now understand this better, so I thank you. The world has moved on and now transpilers are coming into their own, so we do have real choice in the language we use in the browser, which as a programmer is all I want.

BrendanEich 11y ago

tl;dr -- "Dart is good". A fine view, I agree on parts. Your words do nothing to address the very real technical problems that kept DartVM out of Chrome. Stop personalizing everything and study the link I cited.

oso2k 11y ago
It's hard not to personalize things like what Oliver Hunt said in [0], "The issue here isn't "can we make multiple vms live in webkit" it's "can we expose multiple languages to the web", to the former i say obviously as we already do, to the latter I say that we don't want to." The general tone Oliver had was akin to saying only little-endian machines should be supported on the Web. Not because of some technically proven deficiency in the idea of allowing big-endian machines, but because "we don't want to." I can only imagine if such logic had been applied to other parts of the Web. Technical problems always have a solution. [0] https://lists.webkit.org/pipermail/webkit-dev/2011-December/018806.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
- BrendanEich 11y ago
  Oliver is not me, nor has he ever worked for Mozilla. But you are not the OP, so this is all just more mistargeted drive-by and taking-it-too-personally complaining. There are not multiple GC'ed VMs in Safari sharing the DOM, so I bet Oliver was talking about things like JSC as another way to script Apple stuff than Obj-C (now Swift). But that's not material to the DartVM/OilPan vs. Chrome issue.
michaelwww 11y ago
Why does the Java VM run in a browser but the Dart VM is too hard?
- BrendanEich 11y ago
  Please read anything I've written on the topic over the years. Java runs as a plugin, like Flash. It has no deep DOM integration. Both Java and Flash have become security problems, so they're in various penalty boxes, beyond the plugin prison. Back in 1995, when I did JS in the shadow of Java, as a sidekick Robin-the-boy-hostage language, I did the primordial DOM too. Java was in only applets then -- pretty much the same as a plugin. We did connect JS and Java via LiveConnect, which led to the JRI (Warren Harris at Netscape), which led to the JNI. To solve the GC problem, the JRI user had to manage handles for global and local roots. This did not solve the inter-heap cycle problem, however. Netscape never implemented a cycle collector, but we did at Mozilla, based on [Bacon & Rajan, 2001]. It was required for C++ and JS cycle collection. Around that time, IE would still leak memory if you made a C++/JS cycle by capturing certain global object property references in closures. Their C++ side used COM reference counting, so once the cycle closed through JScript, there was no way to drop the cycle-internal refcount. Mozilla's C++/JS cycle collector was originally meant to handle C-Python too (and possibly other languages with full XPCOM/DOM access), since we had an optional integration of that engine, courtesy Mark Hammond of Active State. But both the C-Python integration and the polyglot support in the CC got ripped out. Browsers cannot afford overhead, even mostly-dead (but still hazardous in the 0day sense) code. (Updated to note that LiveConnect is long-gone too. Java is just a plugin.) I suspect you still have not read Filip Pizlo's post at that lists.webkit.org link I left, or the paper it references. Please take more time to study problems before casting aspersions!
  - michaelwww 11y ago
    What aspersions? I've noted your opposition to Dart. You've explained that it has to do with memory management difficulties that seem intractable. I now understand this better, so I thank you. The world has moved on and now transpilers are coming into their own, so we do have real choice in the language we use in the browser, which as a programmer is all I want.