I was wrong about TypeScript part 1(chefama.blog)
chefama.blog
I was wrong about TypeScript part 1
https://chefama.blog/blog/posts/i-was-wrong-about-typescript-1
6 comments
I think what the author is trying to say is that the type system of TypeScript is unsound, while Rust's type system is (hopefully) sound.
It looks like the op is actually talking about structural typing vs nominal typing, which makes more sense bc Rust is nominally typed (newtype pattern, for example), whereas Typescript is structurally typed.
And you’re right, this has nothing to do with type erasure.
And you’re right, this has nothing to do with type erasure.
> In typecript’s not so strict type system, you can cast anything to the `any` type. And from the `any` type, you can cast it to whichever type you wish
Minor correction: this is really more an issue with the `as` operator. For example these also work:
The potentially unsafe step is the down cast. Up casts should always be safe.
`any` just puts you back into the dynamic typing world. It exists so TypeScript can be gradually adopted in JavaScript codebase. At least the use of `any` can be discouraged with linting. But that doesn't work for `as`. Linters don't understand the difference between safe up- and unsafe down casts. So you can only flag all uses of `as` or none.
Minor correction: this is really more an issue with the `as` operator. For example these also work:
user as unknown as NotUser
user as never as NotUser
The potentially unsafe step is the down cast. Up casts should always be safe.
`any` just puts you back into the dynamic typing world. It exists so TypeScript can be gradually adopted in JavaScript codebase. At least the use of `any` can be discouraged with linting. But that doesn't work for `as`. Linters don't understand the difference between safe up- and unsafe down casts. So you can only flag all uses of `as` or none.
The no-unsafe-* type-aware eslint rules are important.
Even with strict mode and noImplicitAny, secret any's can sneak into the codebase for the weirdest reasons (for example, poorly typed libraries. looking at you, Knex).
tseslint saves you from a ton of such gotchas.
Even with strict mode and noImplicitAny, secret any's can sneak into the codebase for the weirdest reasons (for example, poorly typed libraries. looking at you, Knex).
tseslint saves you from a ton of such gotchas.
it's interesting that in this article you see all three: TypeScript, Typescript, and typescript.
> This is fundamentally different from languages like Rust, where the type system can actually guarantee that if you claim to return an Option<T>, you genuinely can’t return null, the compiler enforces the contract at the language level. Rust’s type system doesn’t just trust your annotations; it verifies them.
This design where types are present at compile-time but disappear at runtime is called type erasure, and it's extremely common. For example, Java's generics are type erased. If you have some Java class Foo<T, U>, in the bytecode it will simply become Foo, and T and U will become Object. Therefore, you cannot use runtime introspection to recover their instantiations.
The remark contrasting TypeScript to Rust seems a little confused. Rust also uses type erasure; types and lifetimes are checked by the compiler, then the compiler produces a native executable, which is just machine code and would not contain type information. Option<&T> could be treated as a pointer T*, because the niche optimization ensures that the Option::None variant is represented as 0 or NULL. If C code were to interact with Rust code via FFI, it would be able to pass a value of 0. However, Rust doesn't have a null value the way that it's commonly understood in languages such as Java, C#, or JavaScript, a distinguished value that denotes a "sentinel" reference that does not refer to any object. I would say that the null reference is semantically a higher-level concept, specific to these particular programming languages.
Philosophically, the notion of type erasure goes all the way back to Curry-style (extrinsic) typing, which is contrasted with Church-style (intrinsic) typing. For example, in Curry-style typing, the program (fun x -> x) is the identity function on all types, while in Church-style typing, each type A has its own identity function, (fun (x : A) -> x) and a program is meaningless without types.
Please correct me if I'm wrong or misunderstood!