> 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:
user as unknown as NotUser
user as never as NotUser
`as` let's you cast to arbitrary super- and sub-types. It prevents you from casting to unrelated types directly (here `NotUser`), but you can always use the trick above:
Either cast to the top-type (unknown/any) or bottom-type (never) first, then you have something that's a super-type (sub-type) of everything so you are free to cast back down (up) to an arbitrary type.
The potentially unsafe step is the down cast. Up casts should always be safe.
> TypeScript’s type system is purely structural and exists only at compile time. It has no way to verify that your function actually implements what its signature claims. You can declare that a function transforms a User into a SafeUser, and as long as the return object has the required fields of SafeUser, TypeScript doesn’t care what additional properties might still be lurking in there.
> 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.
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.
> 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:
`as` let's you cast to arbitrary super- and sub-types. It prevents you from casting to unrelated types directly (here `NotUser`), but you can always use the trick above: Either cast to the top-type (unknown/any) or bottom-type (never) first, then you have something that's a super-type (sub-type) of everything so you are free to cast back down (up) to an arbitrary type.The potentially unsafe step is the down cast. Up casts should always be safe.
> TypeScript’s type system is purely structural and exists only at compile time. It has no way to verify that your function actually implements what its signature claims. You can declare that a function transforms a User into a SafeUser, and as long as the return object has the required fields of SafeUser, TypeScript doesn’t care what additional properties might still be lurking in there.
> 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!
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.