[logicchains]

>I think it is way ahead of the JS/TS stack in many regards.

In what ways do you consider it ahead of Typescript? Personally as someone who's particularly fond of static type systems (Haskell and the like), Typescript's type system seems way more advanced and powerful than Dart's (union and intersection types, in particular, and non-nullable types). Map types (introduced in Typescript 2.1) also seem pretty interesting.

[isoos]

Some of my earlier notes are in this thread (it is more about the day-to-day feature I actually use and like, and less about the fine details of the type system) https://news.ycombinator.com/item?id=13371009

Personally I don't get the hype around union types: at the point where you need to check which type you are working with, you may as well use a generic object (and maybe an assert if you are pedantic).

Intersection types may be a nice subtlety in an API, but I haven't encountered any need for it yet. Definitely not a game-changer.

I longed for non-nullable types, but as soon as Dart had the Elvis-operator (e.g. a?.b?.c evaluates null if any of them is null), it is easy to work with nulls. Also, there is a lot of talk about them (either as an annotation for the dart analyzer or as a language feature), so it may happen.

Mapped types are interesting indeed. In certain cases it really helps if you are operating with immutable objects, and mapping helps with that (although does not entirely solves it, because the underlying runtimes does allow changes to the object).

[throwawaydbfif]

I agree about union types. They can quickly result in insane variable declaration statements that are hard to understand.

I dislike nulls though, I always wish people would just use a flag or error handling when objects are undefined, instead of "hey this object is the flag and sometimes it's not actually an object!"

You'd think language designers would learn after dealing with null pointers :)

[willtim]

So Dart hasn't really incorporated any lessons from 20 years of Java, has it? Google's answer to Tony Hoare's billion-dollar mistake is... "The Elvis operator"?

[munificent]

TypeScript has some really cool type system features. Union and intersection types are fun and really handy when interacting with dynamically typed code. (If you go back through history, you'll find almost every language with union types also has a mixture of static and dynamic typing. See: Pike, Typed Racket, etc.)

Self types (the "this" in the return type) is handy.

I can see us adding some of those to Dart eventually.

Non-nullable types are great, which I've said for a very long time[1]. We are finally working to try to add them into Dart[2]. It's early still, but it looks really promising so far. It kills me that I've been saying we should do them for Dart since before TypeScript even existed and still they beat us to the punch, but hopefully we can at least catch up.

The main difference between TypeScript and Dart's type systems (and by the latter I mean strong mode[3], not the original optional type system) is that Dart's type system is actually sound.

This means a Dart compiler using strong mode can safely rely on the types being correct when it comes to dead code elimination, optimization, etc. That is not the case with TypeScript and at this point will likely never be. There is too much extant TypeScript code and JS interop is too important for TypeScript to take the jump all the way to soundness. They gain a lot of ease of adoption from soundness, but they give up some stuff too.

In addition to the above, it means they'll have a hard time hanging new language features on top of static types because the types can be wrong. With Dart, we have the ability to eventually support features like extension methods, conversions, etc. and other things which all require the types to be present and correct.

[1]: http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-...

[2]: https://github.com/dart-lang/sdk/pull/28619

[3]: https://github.com/dart-archive/dev_compiler/blob/master/STR...

[fixermark]

Typescript is definitely an improvement over type-free JS, but it's still wedded to the JS type system so unfortunately, it will still let you shoot yourself in the foot in ways you might not anticipate if you have experience with other languages with a stronger type system.

For example, If you have a string-typed foo and a number-typed bar, "foo + bar" is still a valid statement in TS because they have to maintain backwards-compatibility with JS's unfortunate language design choices.