I disagree with OP, but two interesting corollaries of TS type semantics are its strong type inference and structural typing:

Const x = [{x: 3, y: "hi"}, {x: 9, y: "bye"}];

Automatically gets you x: "Array of {x : number, y: string }". And if you declare the same type somewhere else, as long as they're "structurally equivalent" (i.e. same x and y types) you can actually use them interchangeably. You can't do that e.g. with c#, where one class will never be exchangeable with an unrelated class , no matter how similar the definitions.

This lets you do some funny stuff like"subset type detection ": https://gist.github.com/hraban/66c1778cdd31868034b12db93fcce...

All in all, it's more of an oddity than an actual strength, if you ask me. It's necessary to emulate JS semantics, but I wouldn't consider it an advantage in a new language.

> You can't do that e.g. with c#, where one class will never be exchangeable with an unrelated class , no matter how similar the definitions.

Agreed. Duck typing is a killer feature. I can't say how many time's I've rolled a new class for no reason other than data structuring, which would have been far preferable as something just defined inline.

Mostly, for me, it comes down to union types, intersection types, the ability to disallow implicit nulls (meaning null must be declared as a valid value at the type level, and therefore cannot creep in unexpectedly), string literal types, discriminated unions (most of the good stuff from algebraic data types), and index types.

All demonstrated here: https://www.typescriptlang.org/docs/handbook/advanced-types....

The result is a very nice, expressive way to state your types and get maximal benefit from the type checker.