[catnaroek]

Ironically, Elm's type system is actually one of the simplest out there. No subtyping (unions or intersections), no flow-sensitive typing, just plain first-order type constructors, Hindley-Milner type inference and nice records. Much of the complication in Flow and TypeScript's type systems comes from the need to accommodate existing JavaScript idioms.

[tommyd]

Good point. I suppose what I meant was more that types are at the core of Elm and pervade every part of the language, whereas TS/Flow are adding types on top of a dynamic language and there are parts where it may be difficult or impossible to maintain type safety to the same degree (especially when interacting with non-TS/Flow code)

[seanmcdirmid]

No one has really figured out nominal subtyping + type parameters with good type inference support. The best we can achieve seems to be scala, which still requires more type annotations than many are comfortable with.

[imtringued]

I'm not sure what you're talking about. Can you please elaborate?

[ufo]

The real issue is not nominal vs structural typing. Its the subsumption rule (which says that you can freely use a subtype anywhere a supertype would be expected).

Mixing subtyping with subsumption and parametric polymorphism (type parameters) is really very difficult though. From a theoretic point of view, type inference and type checking are harder. From an usability perspective, the programmer now has to deal with variance annotations (for example, in Java `class List[+T]` means the T parameter is covariant) and bounded polymorphism (for example, things like <? extends T> in Java).

[catnaroek]

Sure. As a member of the extended ML/Haskell family, Elm is inherently typeful, whereas in TS/Flow types are opt-in. But, as it turns out, pragmatically, typefulness actually limits the extent to which a language can become complicated, because the complexity ends up showing in the type system, and that's useful feedback for the language designer that he or she is going in the wrong direction. OTOH, the designer of a non-typeful language can “hide the ball” by not reflecting complexity in types.