5 ms·

> why not help with bignums sooner It's great that Apple and MS are on board with ES6. But even if the V8 team had implemented bignums behind a flag in 2010, d

by xxgreg 12y ago

> why not help with bignums sooner It's great that Apple and MS are on board with ES6. But even if the V8 team had implemented bignums behind a flag in 2010, do you really think that the other vendors would have also implemented it already? I find this scenario unlikely - but you obviously have a better view of this than I do. > Snapshotting would be relatively easy to do with ES6's module system. People would have to refrain from abusing the global object, or snapshotting might fail. I guess you'd need to add some extra restrictions, such as no top level code outside of functions including variable initialisers, and no modification of prototype chains. This seems hard to do with JS as it is written today. Perhaps the "use strong" experiment will make this easier. > ES6 modules plus the asm.js work to avoid loading too much cold code is likely to bear more fruit than a new VM's bespoke snapshotting tech This is your intuition and opinion. Some people disagree, and have chosen to put their effort into another approach. Maybe you're right. Maybe they're right. Personally I think it's better to try both approaches, and let benchmarks settle this. From the benchmarks I've seen, snapshots look very promising. > Dart ain't gonna replace JS in the foreseeable future Flamebait! It doesn't need to. It just needs to provide good development tooling for some developers who prefer using it than vanilla javascript.

BrendanEich 12y ago
Bignums have been on the Harmony agenda for years, going back to: http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:bignums from 2010 (before the Dash memo leaked, before dherman or anyone on TC39 not from Google, and probably any of the folks from Google for that matter, knew that Dart had `int` as bignum). With V8 jumping in, you bet that they'd have been implemented in at least V8 and probably SpiderMonkey -- just as many ES6 features proposed since then have been: http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/ Did you know about these precedents? Serious question. I'm not citing total what-ifs here: we did have bignums on the agenda, but we lacked a V8-level champion; we did -- we the various JS engine implementors -- implement a lot in the last few years. No intuition is required to say that VM isolate snapshotting (if that's truly needed to deal with massive gmail-level cold-code on first load; I see other solutions) could be added to JS if it could be done for Dart. Lars Bak tried asserting no-way-in-JS because of the notorious JS global object. I say: never say never, opt-in is the way the web evolves. The global object is being ring-fenced by ES6 modules and new binding forms. This is not a difference of opinion, it's a matter of choice and funding. Also not flamebait: my point about JS not going away. You switched from "Dart does good for the Web via (eventual) JS uplift" (paraphrasing), to "Dart just needs to provide good development tooling", seemingly in response to my pointing out that there hasn't been much uplift over five years. What's with the goalpost moving, and in a weak direction to boot? You were very much on target citing SIMD flowing from Dart to JS, thanks to John McCutchan, to whom I tweeted the idea when I saw his tweet about Dart SIMD: https://twitter.com/BrendanEich/status/308343704194781186 https://twitter.com/BrendanEich/status/308343704194781186 John replied that he was going to look at JS SIMD next. So thanks to me too -- this Dart => JS transfer was not as far as I can tell on the Dart leaders' agenda, it was bottom up work by John. After our twitter exchange, Mozilla and Intel joined in. The `for (let...)` binding per iteration semantics in ES6 did not come directly from Dart. We'd been working on it for a while in TC39. Here's a note from me about it (find "binding per iteration") from 2009: http://wiki.ecmascript.org/doku.php?id=harmony:let http://wiki.ecmascript.org/doku.php?id=harmony:let It helped to have Dart do it, in the "moral support" and "evidence it is worth the spec/impl complexity" senses. But there was no tech transfer or direct causation. Don't get me wrong, Google cannot spend tens of millions on top talent and make something of zero value. My point about opportunity costs stands. We could have come a lot farther, faster. This is true now as it was in the IE monopoly era (no, I'm not saying things are as bad, just that the hazard of doing WPF or Dart instead of working more directly on the Web stack remains). Complaining about JS as a backward-compatibility-constrained language, to support the idea that JS uplift needs expensive, separate "REPLACE JS" alterna-language/runtime projects such as Dart, which inevitably -- because you can't replace JS, flamebait trigger warning LOL -- backpeddle to compile-to-JS tooling and tardy tech transfer into ECMA-262, doesn't justify the opportunity cost. There are better ways to improve the system we're stuck with, sooner. I'm not religious about this, nor are the V8 folks now working in earnest on SoundScript. You're seeing more of what I'm advocating, finally. It wasn't in evidence for too many years.
- xxgreg 12y ago
  > Complaining about JS as a backward-compatibility-constrained language, to support the idea that JS uplift needs expensive, separate "REPLACE JS" alterna-language/runtime projects such as Dart, which inevitably -- because you can't replace JS, flamebait trigger warning LOL -- backpeddle to compile-to-JS tooling and tardy tech transfer into ECMA-262, doesn't justify the opportunity cost. Ok, let's say JS continues to evolve over the next 5-10 years, and by this time all browsers support integers, optional types, operator overloading, less implicit conversion, and mixins. By this point compiling Dart to JS is trivial, and the cross compiled code is also completely readible. So I can take my existing Dart project and compile it to ES11, clean up a few things by hand, and then continue developing in ES11. In the meantime I've had 5-10 years being very productive developing in Dart with good tool support. This seems like a win to me. Having a VM is also incredibly beneficial for development and debugging. These points alone justify investment in Dart. But there are more benefits. Providing a testing ground for VM engineers to try out new features without legacy compatibility constraints. They haven't really got started on performance yet, and they're already solidly ahead of V8. This can provide insights for TC39, to see what kind of performance/memory improvements are possible if changes are made to the language. > Bignums I'm aware of the bignums strawman, and I'm aware the page on the wiki dates to 2010. But I repeat: even if the V8 team had implemented bignums behind a flag in 2010, do you really think that the other vendors (including MS and Apple) would have also implemented them already? I find this scenario unlikely. (But kudos to MS/A for implementing the new ES6 features. I'm glad to see JS evolving) > [Snapshotting] could be added to JS if it could be done for Dart. My understanding was that the V8 team actually implemented snapshotting and initially used it for loading their JS core library. They didn't think it was possible to use it for loading cached web code. Not because of the globals object, but because javascript code must be executed to build up classes, i.e. setting prototypes etc. Because execution and structure is interleaved, top level code and initialisors could perform side effects before the static program structure exists. > there hasn't been much uplift over five years. It looks like Dart is a longer term bet. It will be interesting to see what kind of an influence it has over the next decade or so. Especially given the recent talk around adding optional typing to JS. The Dart team are also currently experimenting with co-operative threading, growable stacks and concurrency primitives. https://github.com/dart-lang/fletch/wiki/Coroutines-and-Threads https://github.com/dart-lang/fletch/wiki/Coroutines-and-Thre... > My point about opportunity costs stands. We could have come a lot farther, faster. I'm not convinced. I don't see how the development resourcing on the V8 development team could have sped up the ES6 standards process. The ES6 process includes getting consesus with Apple/Microsoft - this process isn't time constrained by V8 development resources. Consider the opportunity cost if they chose not to develop Dart. Developers have to wait a lot longer to get modern tooling, with: completions, doc hovers, code navigation and static analysis. These really make a huge difference to developer productivity. All of the experience gained here can feed back into javascript tooling (assuming optional typing makes it into ES). Also consider the individual developer's motivations. It's great that you are excited about working on JS and spidermonkey year after year. But what were the motivations of the developers at google? If the developers are passionate about the web like yourself, then they can continue to work with the V8 team. But if what excites them, is working on a state of the art dynamically typed VM, well then removing some of the legacy JS constraints allows them freedom to innovate. If their only choice had been to work on V8, they could well leave the company and work on another VM project somewhere else. So what would the cost have been if google management said no you can't do Dart? > You switched from "Dart does good for the Web via (eventual) JS uplift" (paraphrasing), to "Dart just needs to provide good development tooling" ... What's with the goalpost moving ... ? The shifted goal post was: "Dart ain't gonna replace JS in the foreseeable future". I never claimed that Dart will, or needs to, replace javascript.

by xxgreg 12y ago

BrendanEich 12y ago

Bignums have been on the Harmony agenda for years, going back to: http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:bignums from 2010 (before the Dash memo leaked, before dherman or anyone on TC39 not from Google, and probably any of the folks from Google for that matter, knew that Dart had `int` as bignum). With V8 jumping in, you bet that they'd have been implemented in at least V8 and probably SpiderMonkey -- just as many ES6 features proposed since then have been: http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/ Did you know about these precedents? Serious question. I'm not citing total what-ifs here: we did have bignums on the agenda, but we lacked a V8-level champion; we did -- we the various JS engine implementors -- implement a lot in the last few years. No intuition is required to say that VM isolate snapshotting (if that's truly needed to deal with massive gmail-level cold-code on first load; I see other solutions) could be added to JS if it could be done for Dart. Lars Bak tried asserting no-way-in-JS because of the notorious JS global object. I say: never say never, opt-in is the way the web evolves. The global object is being ring-fenced by ES6 modules and new binding forms. This is not a difference of opinion, it's a matter of choice and funding. Also not flamebait: my point about JS not going away. You switched from "Dart does good for the Web via (eventual) JS uplift" (paraphrasing), to "Dart just needs to provide good development tooling", seemingly in response to my pointing out that there hasn't been much uplift over five years. What's with the goalpost moving, and in a weak direction to boot? You were very much on target citing SIMD flowing from Dart to JS, thanks to John McCutchan, to whom I tweeted the idea when I saw his tweet about Dart SIMD: https://twitter.com/BrendanEich/status/308343704194781186 https://twitter.com/BrendanEich/status/308343704194781186 John replied that he was going to look at JS SIMD next. So thanks to me too -- this Dart => JS transfer was not as far as I can tell on the Dart leaders' agenda, it was bottom up work by John. After our twitter exchange, Mozilla and Intel joined in. The `for (let...)` binding per iteration semantics in ES6 did not come directly from Dart. We'd been working on it for a while in TC39. Here's a note from me about it (find "binding per iteration") from 2009: http://wiki.ecmascript.org/doku.php?id=harmony:let http://wiki.ecmascript.org/doku.php?id=harmony:let It helped to have Dart do it, in the "moral support" and "evidence it is worth the spec/impl complexity" senses. But there was no tech transfer or direct causation. Don't get me wrong, Google cannot spend tens of millions on top talent and make something of zero value. My point about opportunity costs stands. We could have come a lot farther, faster. This is true now as it was in the IE monopoly era (no, I'm not saying things are as bad, just that the hazard of doing WPF or Dart instead of working more directly on the Web stack remains). Complaining about JS as a backward-compatibility-constrained language, to support the idea that JS uplift needs expensive, separate "REPLACE JS" alterna-language/runtime projects such as Dart, which inevitably -- because you can't replace JS, flamebait trigger warning LOL -- backpeddle to compile-to-JS tooling and tardy tech transfer into ECMA-262, doesn't justify the opportunity cost. There are better ways to improve the system we're stuck with, sooner. I'm not religious about this, nor are the V8 folks now working in earnest on SoundScript. You're seeing more of what I'm advocating, finally. It wasn't in evidence for too many years.

xxgreg 12y ago
> Complaining about JS as a backward-compatibility-constrained language, to support the idea that JS uplift needs expensive, separate "REPLACE JS" alterna-language/runtime projects such as Dart, which inevitably -- because you can't replace JS, flamebait trigger warning LOL -- backpeddle to compile-to-JS tooling and tardy tech transfer into ECMA-262, doesn't justify the opportunity cost. Ok, let's say JS continues to evolve over the next 5-10 years, and by this time all browsers support integers, optional types, operator overloading, less implicit conversion, and mixins. By this point compiling Dart to JS is trivial, and the cross compiled code is also completely readible. So I can take my existing Dart project and compile it to ES11, clean up a few things by hand, and then continue developing in ES11. In the meantime I've had 5-10 years being very productive developing in Dart with good tool support. This seems like a win to me. Having a VM is also incredibly beneficial for development and debugging. These points alone justify investment in Dart. But there are more benefits. Providing a testing ground for VM engineers to try out new features without legacy compatibility constraints. They haven't really got started on performance yet, and they're already solidly ahead of V8. This can provide insights for TC39, to see what kind of performance/memory improvements are possible if changes are made to the language. > Bignums I'm aware of the bignums strawman, and I'm aware the page on the wiki dates to 2010. But I repeat: even if the V8 team had implemented bignums behind a flag in 2010, do you really think that the other vendors (including MS and Apple) would have also implemented them already? I find this scenario unlikely. (But kudos to MS/A for implementing the new ES6 features. I'm glad to see JS evolving) > [Snapshotting] could be added to JS if it could be done for Dart. My understanding was that the V8 team actually implemented snapshotting and initially used it for loading their JS core library. They didn't think it was possible to use it for loading cached web code. Not because of the globals object, but because javascript code must be executed to build up classes, i.e. setting prototypes etc. Because execution and structure is interleaved, top level code and initialisors could perform side effects before the static program structure exists. > there hasn't been much uplift over five years. It looks like Dart is a longer term bet. It will be interesting to see what kind of an influence it has over the next decade or so. Especially given the recent talk around adding optional typing to JS. The Dart team are also currently experimenting with co-operative threading, growable stacks and concurrency primitives. https://github.com/dart-lang/fletch/wiki/Coroutines-and-Threads https://github.com/dart-lang/fletch/wiki/Coroutines-and-Thre... > My point about opportunity costs stands. We could have come a lot farther, faster. I'm not convinced. I don't see how the development resourcing on the V8 development team could have sped up the ES6 standards process. The ES6 process includes getting consesus with Apple/Microsoft - this process isn't time constrained by V8 development resources. Consider the opportunity cost if they chose not to develop Dart. Developers have to wait a lot longer to get modern tooling, with: completions, doc hovers, code navigation and static analysis. These really make a huge difference to developer productivity. All of the experience gained here can feed back into javascript tooling (assuming optional typing makes it into ES). Also consider the individual developer's motivations. It's great that you are excited about working on JS and spidermonkey year after year. But what were the motivations of the developers at google? If the developers are passionate about the web like yourself, then they can continue to work with the V8 team. But if what excites them, is working on a state of the art dynamically typed VM, well then removing some of the legacy JS constraints allows them freedom to innovate. If their only choice had been to work on V8, they could well leave the company and work on another VM project somewhere else. So what would the cost have been if google management said no you can't do Dart? > You switched from "Dart does good for the Web via (eventual) JS uplift" (paraphrasing), to "Dart just needs to provide good development tooling" ... What's with the goalpost moving ... ? The shifted goal post was: "Dart ain't gonna replace JS in the foreseeable future". I never claimed that Dart will, or needs to, replace javascript.