I was wrong about TypeScript part 1

> 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!

> 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.

`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.

it's interesting that in this article you see all three: TypeScript, Typescript, and typescript.