5 ms·

BrendenEich said this of Dart, 2 years ago on HN, and might help explain OP's sentiment: For the record, I'm not worried about JS being replaced by a better la

by wamatt 13y ago

BrendenEich said this of Dart, 2 years ago on HN, and might help explain OP's sentiment: For the record, I'm not worried about JS being replaced by a better language. I am working to do that within Ecma TC39, by evolving JS aggressively. The leaked Google doc's assertion that this is impossible and that a "clean break" is required to make significant improvements is nonsense, a thin rationale for going it alone rather than cooperating fully. The big issue I have with Dart, which you seem to consider inconsequential, is whether Google forks the web developer community, not just its own paid developers, with Dart, and thereby fragments web content. A Dart to JS compiler will never be "decent" compared to having the Dart VM in the browser. Yet I guarantee you that Apple and Microsoft (and Opera and Mozilla, but the first two are enough) will never embed the Dart VM. So "Works best in Chrome" and even "Works only in Chrome" are new norms promulgated intentionally by Google. We see more of this fragmentation every day. As a user of Chrome and Firefox (and Safari), I find it painful to experience, never mind the political bad taste. Ok, counter-arguments. What's wrong with playing hardball to advance the web, you say? As my blog tries to explain, the standards process requires good social relations and philosophical balance among the participating competitors. Google's approach with Dart is thus pretty much all wrong and doomed to leave Dart in excellent yet non-standardized and non-interoperable implementation status. Dart is GBScript to NaCl/Pepper's ActiveG. Could Google, unlike Microsoft ten or so years ago, prevail? Only by becoming the new monopoly power on the web. We know how that story ends. https://news.ycombinator.com/item?id=2982949 https://news.ycombinator.com/item?id=2982949 EDIT: updated to the long form quote, for additional context.

golergka 13y ago
> A Dart to JS compiler will never be "decent" compared to having the Dart VM in the browser. I'm new to javascript & dart, so honest question here: why?
- k3n 13y ago
  Because it is a Google project, and other browser vendors (those mentioned in Eich's next sentence) don't want to include something from a competitor into their own browser. It'd be about like Ford proposing that GM and Dodge install Ford's GPS unit (hopefully you can relate to major US automakers). He might have spoken too soon though (or I missed the point), as there are projects out now that I think could very well make a decent runtime for Dart. Using tech such as asm.js[1] -- which Firefox now includes natively (drawing a parallel to Google's Dart) -- along with new versions of JS, and modern JS browser optimizations....it can make for a very efficient script. As efficient as Dart with the VM? Probably not, but I'm not sure just how much of the market you're going to corner by such an advantage. Any JS outside of a browser will undoubtedly run on NodeJS, which is going to be more efficient than Dart for most (if not all) tasks, and so it just comes to down to in-browser usage. For 99.99% of current web apps, I don't think you'd never notice a difference. 1. http://en.wikipedia.org/wiki/Asm.js http://en.wikipedia.org/wiki/Asm.js
- rdtsc 13y ago
  Don't listen to the hate and vitriol. Dart has a nice IDE, good clean types and language design. People are upset because they jumped on the wrong band-wagon and now something shiner and newer came around so they are not the cool hipsters anymore. Kind of like in the kindergarten the kid with the shiny new bike is boasting then some other kid gets the later, better, shinier model, the first gets upset and throws a tantrum. Look at Dart's performance benchmarks. Its DartVM is about 2x as fast as v8 (JS) and its compiled to JS version is on par with v8. https://www.dartlang.org/performance/ https://www.dartlang.org/performance/
  - pcwalton 13y ago
    > Dart has a nice IDE, good clean types and language design. I have a serious problem with Dart's design: the type system is deliberately unsound around generics because the designers apparently think that supporting variance (which is not that difficult!) is worse than having types tell the truth. I would much rather there be no type system at all than there to be an unsound one, as I don't think compilers and IDE's should lie to you. I think that's a mistake that the new language of the Web should not make, but Google seems unwilling to change it. Unlike JavaScript's warts, which be worked around for the most part, I don't see any way to fix a flaw that serious in the type system once Dart is stable.
    - discreteevent 13y ago
      I don't understand this. Dart is a dynamic language that gives you the option of adding types that help with tooling, documentation and some type checking at design time. At run time you can run it in checked mode and it will always tell the truth. This means that if you cover your code at all, manually or automatically then it will inform you of type errors. If you don't cover your code before releasing it then you probably are not writing anything very serious anyway. How is this worse than a dynamic language that offers you no optional typing with full checking at runtime?
      - pcwalton 13y ago
        > Dart is a dynamic language that gives you the option of adding types that help with tooling, documentation and some type checking at design time. But the tooling and documentation aren't telling you what will happen at runtime. > At run time you can run it in checked mode and it will always tell the truth. It doesn't tell you the truth. A static type system is designed to rule out errors are compile time. That's what makes a static type system different from type assertions or guards. Besides, I don't really know what "telling you the truth" means if, for example, function arguments unify under covariance instead of contravariance like they should. Whether that happens at runtime or at compile time makes no difference—it's equally wrong either way. > This means that if you cover your code at all, manually or automatically then it will inform you of type errors. This is always true in any dynamic language. > How is this worse than a dynamic language that offers you no optional typing with full checking at runtime? In JS's case we can still add a static type system that's actually sound, whereas Dart has already crossed the bridge into unsoundness.
jgon 13y ago
And here we are 2 years later, TC39 is still nowhere in sight, Javascript is still, in the eyes of anyone with an ounce of taste, a terrible language for large scale development and Dart continues to iterate while offering all of it's advancements as it compiles to JS. I honestly don't even care if Dart doesn't take off, maybe clojurescript or something similar will instead. But my god something needs to happen in this space because the JS standards body has spent almost 2 decades aggresively doing nothing about the many gaping, egregious flaws in Javascript. Its 2013 and we don't have lexical scoping as standard, but hey let's dick around in committee for another year packing in generators, etc, etc, etc. I would honestly put a lot more weight in Brenden Eich's words if the state of Javascript and web dev wasn't so absolutely dismal and if he wasn't trying to crap on a project actually working to do something about it.
- steveklabnik 13y ago
  > TC39 is nowhere in sight Uhhhh TC39 meets bi-monthly. If you meant ECMASCRIPT 6, it's targeting finalization next month. Furthermore, future releases are set to be much, much faster than previous ones.
  - jgon 13y ago
    Yes I meant the standard produced by TC39, of which Ecmascript 6 is the new version. My apologies for loose use of terminology. I would be somewhat happy if ES6 was finalized next month, but if it slipped (again) I would not be surprised. You'll also have to forgive me if I am skeptical of claims about the increased speed of future standards. The burden is on TC39 to prove this to me and I reserve the right be skeptical based on prior evidence until I see otherwise.
    - domenicd 13y ago
      ES6 features are already shipping in many browsers. http://kangax.github.io/es5-compat-table/es6/ http://kangax.github.io/es5-compat-table/es6/
- rdtsc 13y ago
pekk 13y ago
"forks the web developer community, not just its own paid developers" Brendan Eich does not have a right to anybody else's effort. It is totally unreasonable to use artificial means to trap people on languages they have problems with, just because you want control of more of the programming world for yourself.

by wamatt 13y ago

golergka 13y ago

> A Dart to JS compiler will never be "decent" compared to having the Dart VM in the browser. I'm new to javascript & dart, so honest question here: why?

k3n 13y ago
Because it is a Google project, and other browser vendors (those mentioned in Eich's next sentence) don't want to include something from a competitor into their own browser. It'd be about like Ford proposing that GM and Dodge install Ford's GPS unit (hopefully you can relate to major US automakers). He might have spoken too soon though (or I missed the point), as there are projects out now that I think could very well make a decent runtime for Dart. Using tech such as asm.js[1] -- which Firefox now includes natively (drawing a parallel to Google's Dart) -- along with new versions of JS, and modern JS browser optimizations....it can make for a very efficient script. As efficient as Dart with the VM? Probably not, but I'm not sure just how much of the market you're going to corner by such an advantage. Any JS outside of a browser will undoubtedly run on NodeJS, which is going to be more efficient than Dart for most (if not all) tasks, and so it just comes to down to in-browser usage. For 99.99% of current web apps, I don't think you'd never notice a difference. 1. http://en.wikipedia.org/wiki/Asm.js http://en.wikipedia.org/wiki/Asm.js
rdtsc 13y ago
Don't listen to the hate and vitriol. Dart has a nice IDE, good clean types and language design. People are upset because they jumped on the wrong band-wagon and now something shiner and newer came around so they are not the cool hipsters anymore. Kind of like in the kindergarten the kid with the shiny new bike is boasting then some other kid gets the later, better, shinier model, the first gets upset and throws a tantrum. Look at Dart's performance benchmarks. Its DartVM is about 2x as fast as v8 (JS) and its compiled to JS version is on par with v8. https://www.dartlang.org/performance/ https://www.dartlang.org/performance/
- pcwalton 13y ago
  > Dart has a nice IDE, good clean types and language design. I have a serious problem with Dart's design: the type system is deliberately unsound around generics because the designers apparently think that supporting variance (which is not that difficult!) is worse than having types tell the truth. I would much rather there be no type system at all than there to be an unsound one, as I don't think compilers and IDE's should lie to you. I think that's a mistake that the new language of the Web should not make, but Google seems unwilling to change it. Unlike JavaScript's warts, which be worked around for the most part, I don't see any way to fix a flaw that serious in the type system once Dart is stable.
  - discreteevent 13y ago
    I don't understand this. Dart is a dynamic language that gives you the option of adding types that help with tooling, documentation and some type checking at design time. At run time you can run it in checked mode and it will always tell the truth. This means that if you cover your code at all, manually or automatically then it will inform you of type errors. If you don't cover your code before releasing it then you probably are not writing anything very serious anyway. How is this worse than a dynamic language that offers you no optional typing with full checking at runtime?
    - pcwalton 13y ago
      > Dart is a dynamic language that gives you the option of adding types that help with tooling, documentation and some type checking at design time. But the tooling and documentation aren't telling you what will happen at runtime. > At run time you can run it in checked mode and it will always tell the truth. It doesn't tell you the truth. A static type system is designed to rule out errors are compile time. That's what makes a static type system different from type assertions or guards. Besides, I don't really know what "telling you the truth" means if, for example, function arguments unify under covariance instead of contravariance like they should. Whether that happens at runtime or at compile time makes no difference—it's equally wrong either way. > This means that if you cover your code at all, manually or automatically then it will inform you of type errors. This is always true in any dynamic language. > How is this worse than a dynamic language that offers you no optional typing with full checking at runtime? In JS's case we can still add a static type system that's actually sound, whereas Dart has already crossed the bridge into unsoundness.

jgon 13y ago

And here we are 2 years later, TC39 is still nowhere in sight, Javascript is still, in the eyes of anyone with an ounce of taste, a terrible language for large scale development and Dart continues to iterate while offering all of it's advancements as it compiles to JS. I honestly don't even care if Dart doesn't take off, maybe clojurescript or something similar will instead. But my god something needs to happen in this space because the JS standards body has spent almost 2 decades aggresively doing nothing about the many gaping, egregious flaws in Javascript. Its 2013 and we don't have lexical scoping as standard, but hey let's dick around in committee for another year packing in generators, etc, etc, etc. I would honestly put a lot more weight in Brenden Eich's words if the state of Javascript and web dev wasn't so absolutely dismal and if he wasn't trying to crap on a project actually working to do something about it.

steveklabnik 13y ago
> TC39 is nowhere in sight Uhhhh TC39 meets bi-monthly. If you meant ECMASCRIPT 6, it's targeting finalization next month. Furthermore, future releases are set to be much, much faster than previous ones.
- jgon 13y ago
  Yes I meant the standard produced by TC39, of which Ecmascript 6 is the new version. My apologies for loose use of terminology. I would be somewhat happy if ES6 was finalized next month, but if it slipped (again) I would not be surprised. You'll also have to forgive me if I am skeptical of claims about the increased speed of future standards. The burden is on TC39 to prove this to me and I reserve the right be skeptical based on prior evidence until I see otherwise.
  - domenicd 13y ago
    ES6 features are already shipping in many browsers. http://kangax.github.io/es5-compat-table/es6/ http://kangax.github.io/es5-compat-table/es6/
rdtsc 13y ago

pekk 13y ago

"forks the web developer community, not just its own paid developers" Brendan Eich does not have a right to anybody else's effort. It is totally unreasonable to use artificial means to trap people on languages they have problems with, just because you want control of more of the programming world for yourself.