He writes:

"And in order to understand why that’s the case, you need to start digging into the workings of the type system (hence a leaky abstraction)."

Then he proceeds to just write more Typescript without dropping down to reading the Typescript compiler source code, which is what generally happens when you have to deal with a leaky abstraction.

When you have an ORM that generates SQL, but you have to read the generated SQL for performance reasons (N+1, etc), that's a leaky abstraction. The details end up leaking through.

This doesn't work with Typescript, since Typescript types don't appear in the generated Javascript code. The type system doesn't try to hide an underlying system that could possibly leak through. The type system is a new thing that wasn't there before.

What's particularly annoying about the blog post is that the topic at hand actually has very little to do with type systems. It's primarily about compile time evaluation of code. The keys needed for map access need to be known at compile time and by threading them through an if(Math.random() < 0.5), or a keys = keys.map(x => x); the compiler would have to evaluate every possible code path symbolically to generate a type signature. After all, the code could have been keys.map(x => x + "abc") or any other arbitrary expression that can be evaluated at compile time.

The compiler doesn't really give a damn about the types here, because they are kind of irrelevant and crystalize out of the results of compile time evaluation. keys.map(x => x) and keys.map(x => x + "abc") both take a list of strings and output a list of strings. The types are exactly as you expect, but the concrete values are different.

The only way out of this with a type system would be to encode values into the type system itself, which is kind of antithetical to the idea of typing.