[leononame]

C is famously unsafe. But in Java/C#, you do have runtime type safety. You can't just cast something to something else and call it a day. In the worst case, you'll get an exception telling you that this does not work. In TypeScript, the "cast" succeeds, but then 200 lines later, you get some weird runtime error like "does not exist on type undefined" which doesn't tell you at all what the source of the error is.

In TypeScript, a variable can have a different runtime type from its declared type entirely, that's just not true for many other languages

[trashburger]

I'm not sure about the CLR, but the JVM has no type safety whatsoever. Java the language does, but all of that goes away once you are in the JVM bytecode.

[drewhk]

> the JVM has no type safety whatsoever.

This is just partially true (or completely untrue in the mathematical sense since your statement is "_no_ type safety _whatsoever_" :P ). The whole purpose of the bytecode verifier is to ensure that the bytecode accesses objects according to their known type and this is enforced at classloading time. I think you meant type erasure which is related - generic types do not exist on the bytecode level, their type parameters are treated as Object. This does not violate the bytecode verifier's static guarantees of memory safety (since those Objects will be cast and the cast will be verified at runtime), but indeed, it is not a 100% mapping of the Java types - nevertheless, it is still a mapping and it is typed, just on a reduced subset.