logoalt Hacker News

Tade0today at 7:56 AM1 replyview on HN

Regarding TypeScript:

> but types lie at runtime (unsound) requiring you to add your own runtime checks.

I don't recall doing that outside of situations when data is crossing system boundaries.

The vast majority of languages have an unsound type system, yet people are productive in them.

Over the years I've come to realise it's a form of nitpicking. You absolutely need it in some applications, but it's not an important requirement most of the time and it's given undue importance by some.


Replies

teaearlgraycoldtoday at 8:37 AM

The main problem with TypeScript is the default compiler flags are not safe. I understand having things weak when you’re getting the ecosystem up and running, before you have wide adoption. You don’t want to throw too many red squigglies at early adopters and cause them to give up. But these days the default should not allow any. No implicit any. No explicit any. The stdlib should not use it. JSON.parse() should return either unknown or a recursive union that defines all valid JSON structures.

I believe it’s largely because of these defaults that the idea that TypeScript isn’t really checking types persists. Without the any type, or loose undefined and null checks, your types are as validated as they can be. The only failure point is deserialization or an import which doesn’t type check. And deserialization has this problem in every language.

When you compile C to machine code the executed binary isn’t checking types. This is no different from Typescript that’s been compiled to JavaScript.

show 2 replies