4 ms·

At least in my view, there's a couple of big things: Dart doesn't introduce that many advantages over JS for all of its differences, and TS introduces many of t

At least in my view, there's a couple of big things: Dart doesn't introduce that many advantages over JS for all of its differences, and TS introduces many of them with a smaller diff; there's also the presentation of it—Dart was originally presented as a wholesale replacement of Dart, to ship in all browsers, the language more or less as a fait accompli, which rubs plenty of people the wrong way.

markdog12 10y ago
> Dart doesn't introduce that many advantages over JS for all of its differences As someone with experience in both languages, I could not disagree more. > Dart was originally presented as a wholesale replacement of Dart I think you meant replacement of JS here. I guess it depends entirely on what you think of JS as a language. I, for one, would rather a language that fixes core issues with JS, instead of just being a superset of JS.
- gsnedders 10y ago
  > I think you meant replacement of JS here. I guess it depends entirely on what you think of JS as a language. I, for one, would rather a language that fixes core issues with JS, instead of just being a superset of JS. If I were aiming to replace JS, I'd fix what Dart does, but I wouldn't stop with merely fixing what Dart does. Dart, despite being an entirely new language, has a less expressive type system than TS. It's transpiler (and it's VM) also does no optimisation based on the type system, instead heavily relying on the JIT to infer what the types already imply (e.g., it would be nice to do things like LICM at compile-time).
  - markdog12 10y ago
    > has a less expressive type system than TS Care to elaborate on that? As for the rest of your comment, I'm with ya. I guess they're reasoning behind that was they thought a lot of development would start out untyped with additional types added as development progressed. I think that assumption didn't pan out, at least that's not how I do it. Official answer from https://www.dartlang.org/faq https://www.dartlang.org/faq: "Q. But don’t you need sound typing information to get high performance? Sound types can help with performance but aren’t essential. What we need are uniform, simple semantics. Modern VMs can use actual runtime behavior as a valuable signal for optimizations."
    - logicchains 10y ago
      >Care to elaborate on that? I'm not the OP, but TypeScript supports union types (A | B ; a type that can be either type A or type B) and intersection types (A & B ; a type that is both A and B), while Dart doesn't. https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... Typescript also has structural types, like Go and OCaml, which many people find nicer than nominal types. Structural types mean if I have an interface Blaz with two methods Foo and Bar, if I have an object MyObject with Foo and Bar methods of the same types then my object counts as a Blaz, while nominal types mean I have to write something like MyObject extends Blaz.
    - skybrian 10y ago
      That's how dart2js works today but the goal for Dart 2.0 is to move to a sound type system. The beginning of this is available today as "strong mode" and the Dart Dev Compiler.
- coldtea 10y ago
  >As someone with experience in both languages, I could not disagree more. Elaborate then. Because one's major advantages can be another's (and sometimes, objective) trivialities...
  - markdog12 10y ago
    https://www.dartlang.org/guides/language/language-tour https://www.dartlang.org/guides/language/language-tour
pekk 10y ago
What do you mean "fait accompli"? Was the Dart team supposed to give the community a chance to abort the language from existing, and the community was upset that it was completed and published without the input of people who wanted it not to be?
- coldtea 10y ago
  >Was the Dart team supposed to give the community a chance to abort the language from existing No, he means that the Dart team was supposed to solicitate opinions on how to build Dart and what the best objectives for it would be, but instead they showcased it in "almost done" form, and only then tried to attract a community.
  - gsnedders 10y ago
    This. While yes, it was a long way from "standardised" and a lot changed between what Google initially published and the Ecma standard, many fundamental design decisions were made internally and there was never any real influence externally over that. Those are fundamental design decisions where to change them you essentially need to start from scratch. The other big problem was that it was done with the VM being a major part of the project with the intent of getting it into Chrome, obviously without having talked that much with several of the people who have significant influence over such things in (then) WebKit, even those within Google. That the VM was going to be outright objected was entirely predictable.
- deleted 10y ago
  [deleted]
monyr75 10y ago
Your view seems to be from someone who hasn't used Dart extensively, because no one who had would minimize its advantages this way. Being different from JS is the whole point. Dart introduces all the advantages of TS and more, while leaving the baggage and bullshit of JS behind.

markdog12 10y ago

> Dart doesn't introduce that many advantages over JS for all of its differences As someone with experience in both languages, I could not disagree more. > Dart was originally presented as a wholesale replacement of Dart I think you meant replacement of JS here. I guess it depends entirely on what you think of JS as a language. I, for one, would rather a language that fixes core issues with JS, instead of just being a superset of JS.

gsnedders 10y ago
> I think you meant replacement of JS here. I guess it depends entirely on what you think of JS as a language. I, for one, would rather a language that fixes core issues with JS, instead of just being a superset of JS. If I were aiming to replace JS, I'd fix what Dart does, but I wouldn't stop with merely fixing what Dart does. Dart, despite being an entirely new language, has a less expressive type system than TS. It's transpiler (and it's VM) also does no optimisation based on the type system, instead heavily relying on the JIT to infer what the types already imply (e.g., it would be nice to do things like LICM at compile-time).
- markdog12 10y ago
  > has a less expressive type system than TS Care to elaborate on that? As for the rest of your comment, I'm with ya. I guess they're reasoning behind that was they thought a lot of development would start out untyped with additional types added as development progressed. I think that assumption didn't pan out, at least that's not how I do it. Official answer from https://www.dartlang.org/faq https://www.dartlang.org/faq: "Q. But don’t you need sound typing information to get high performance? Sound types can help with performance but aren’t essential. What we need are uniform, simple semantics. Modern VMs can use actual runtime behavior as a valuable signal for optimizations."
  - logicchains 10y ago
    >Care to elaborate on that? I'm not the OP, but TypeScript supports union types (A | B ; a type that can be either type A or type B) and intersection types (A & B ; a type that is both A and B), while Dart doesn't. https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... Typescript also has structural types, like Go and OCaml, which many people find nicer than nominal types. Structural types mean if I have an interface Blaz with two methods Foo and Bar, if I have an object MyObject with Foo and Bar methods of the same types then my object counts as a Blaz, while nominal types mean I have to write something like MyObject extends Blaz.
  - skybrian 10y ago
    That's how dart2js works today but the goal for Dart 2.0 is to move to a sound type system. The beginning of this is available today as "strong mode" and the Dart Dev Compiler.
coldtea 10y ago
>As someone with experience in both languages, I could not disagree more. Elaborate then. Because one's major advantages can be another's (and sometimes, objective) trivialities...
- markdog12 10y ago
  https://www.dartlang.org/guides/language/language-tour https://www.dartlang.org/guides/language/language-tour

pekk 10y ago

What do you mean "fait accompli"? Was the Dart team supposed to give the community a chance to abort the language from existing, and the community was upset that it was completed and published without the input of people who wanted it not to be?

coldtea 10y ago
>Was the Dart team supposed to give the community a chance to abort the language from existing No, he means that the Dart team was supposed to solicitate opinions on how to build Dart and what the best objectives for it would be, but instead they showcased it in "almost done" form, and only then tried to attract a community.
- gsnedders 10y ago
  This. While yes, it was a long way from "standardised" and a lot changed between what Google initially published and the Ecma standard, many fundamental design decisions were made internally and there was never any real influence externally over that. Those are fundamental design decisions where to change them you essentially need to start from scratch. The other big problem was that it was done with the VM being a major part of the project with the intent of getting it into Chrome, obviously without having talked that much with several of the people who have significant influence over such things in (then) WebKit, even those within Google. That the VM was going to be outright objected was entirely predictable.
deleted 10y ago
[deleted]

monyr75 10y ago

Your view seems to be from someone who hasn't used Dart extensively, because no one who had would minimize its advantages this way. Being different from JS is the whole point. Dart introduces all the advantages of TS and more, while leaving the baggage and bullshit of JS behind.