[ClayFerguson]

If you want to trade contrarian jabs, I can play that game: TypeScript does far more than 'mitigate symptoms of type unsafeness' it is a fully type-safe language that will get proper compile-time errors if you use the wrong type. It doesn't "mitigate" unsafeness. It ELIMINATES unsafeness.

[automatwon]

When comparing the types of function parameters, assignment succeeds if either the source parameter is assignable to the target parameter, or vice versa. This is UNSOUND because a caller might end up being given a function that takes a more specialized type, but invokes the function with a less specialized type.

A Google query for the definition of unsound: "not safe or robust"

https://www.typescriptlang.org/docs/handbook/type-compatibil...

You're portraying TypeScript as if it's perfect. Typescript is is permissive and structurally, rather than nominally typed. This is not TypeScript's fault. There will always be tradeoffs. Among other things in the FAQ, there is a section on how to prevent two types from being structurally incompatible. "A possible FIX if you really want two types to be incompatible is to add a 'brand' member"...

https://github.com/Microsoft/TypeScript/wiki/FAQ#type-system...

[ClayFerguson]

The 'assignability rules' of TS catches type-errors in a way that 'solves' all the problems JS ever had. You can critique the nature of that solution if you want (after all, there are an infinite number of solutions in the solution-set), but I think it's a perfect solution.

Give any good developer TS to code in, and he'll know how to use it to check every type in every variable, class, or method parameter, and the checking will be 100% perfectly reliable. That's what I mean by "problem solved".

[automatwon]

Google's closure compiler already addressed that

[ClayFerguson]

Yeah, that's what I just said.