Nice! Didn't realize this was a thing. I suspect they could make even more aggressive optimizations if they made a TS version.

This idea is probably worth a post of its own. I believe that because TypeScript's type system is effectively advisory rather than guaranteed ('unsound'), you cannot rely on it for optimization unless you're willing to unpredictably break programs.

Hey, that’s an interesting thought!

If you go all the way and make it sound with variance annotations, banning asserts & under specified types, etc. then you end up with a language that sucks to use in practice.

If you go to the other extreme, you don’t have static types at all.

If different parts of your code are typed to varying degrees, or you use a lot of unsound types/inferences, maybe there’s a way to assign a confidence score to every type to indicate how accurate you think it is. Maybe there’s a clever way to statically compute that score, or you can instrument some % of prod traffic at runtime to observe types with lower confidence (Node has this, or see MonkeyType or Reticulated Python). Then take that info and feed it into Closure compiler.

> If you go all the way and make it sound with variance annotations

Variance annotations aren't quite what would make the language (in strict mode) sound. Specifically, what makes it unsound is the `any` type (generally) and the lack of enforced variance on methods, non-function properties, and index signatures. It doesn't need annotations to determine variance - type parameter variance can be inferred from where in a type a type parameter is used. It already does so for functions (that's the strict flag's strictFunctionTypes subflag). The real issue is that far, far too many people rely on, eg, unsound array assignments (array aughta be invariant over what it contains but it's often treated covariantly), for it to be reasonable to be a default. However it could always be changed (or added) in the future - that's what the strictness flags are for, ideally; providing ways to ratchet up the safety such that it won't permanently break longtime users of the language.

As far as I understand it, every sound language eventually has to fall back to runtime checks to maintain soundness in tricky cases. For array covariance I know that Java/Dart eventually use runtime checks on array accesses to verify the types work out.

However, it's kind of against the spirit of TypeScript to insert runtime checks. For example because the type system models 'undefined', to model out of bounds array accesses you'd either need to make every array access have type T|undefined or insert bounds checks that throw. (I believe Dart does the latter.)

Totally agreed. The reason to have variance annotations is the language becomes unusable without them. Thats why so many languages with object subtyping support them.