It is all an illusion. Unicode, ASCII, base 10 numbers, are all lies. Our CPUs know binary registers of certain sizes, ints and floats, and nothing else.
Everything else is a lie that we make work by throwing a lot electricity at a lot of fancy sand and out the other end comes something that looks reasonable.
That said, TS has a really nice type system that is absurdly flexible and at times quite fun to use.
I say the phrase "TypeScript crimes" a lot, and it is almost always a positive.
Most programmers I work with and have worked with are not wielding the type system in the same way, and that's usually okay--because I tend to be the one building the libraries they then use, and the compiler keeps folks from doing things with my code that I didn't plan for.
I have some bad news for you about the types in Python--which, for the record, I really like and have made me willing to write Python!--if your objection is that the types are "just an illusion". Much like Pydantic, good use of TypeScript types involves shape validation on input.
(I have worse news for you about C or C++ or anything that isn't typed exclusively based on how wide its register is, but that's nitpicking.)
Honestly, if I'm going to nitpick myself, even that isn't a true statement. You might have an integer/float divide for your registers, like amd64 does, but even past that it's squishy and becomes human bookkeeping or compiler magic. Is %rax an 8-byte integer, or is it a pointer? Or is it garbage because you used %eax (the lower 4 bytes of %rax) for storing a 4-byte integer, and the top half is whatever(tm)? Ditto again for %ax (2-byte) or %al (1-byte). You have widths, but me calling them types was really even a stretch there.
And then everything else is just built from that, really. Strings/arrays? Either length+bytes/charpoints (hope you counted correctly) or "bytes/charpoints until you hit a NUL" (hope you put the NUL in or now your buffers are spewing somewhere they shouldn't). Structs? Pile of bytes, each of them special-cased by the compiler. (A polymorphic class would then have some virtual function tables somewhere too.) And if your language has a fixed-point decimal class, it's time to get weird.
Types are a really convenient, really helpful concept, but to sniff at them being compiler-only in something like TypeScript or typed Python is IMO misguided--because compilers have gotten pretty smart and it allows us to reasonably make flexibility tradeoffs because those compilers are good at doing things. Java will scream at runtime if I cast an object to something it can't be, and that's great, but also, I just won't do that if I validated my inputs in Python with something like Pydantic or TypeScript with something like Zod or Typebox or whatever, because an illegal action with a type becomes a compiler error. So, IMO, let's get over the argument and get back to making stuff. (Even the Golang people. All is forgiven, mostly.)
The problem with Python specifically is that the type system is such a massive bolted-on hack. It has to be, because it's such a dynamic language that all declarations and imports are executable statements - and it's hard to reconcile it with type declarations, which often need to be mutually recursive.
It is kind of hacky for sure, but I've gotten way more productive with it than I've ever been with Python before. Like I went my entire career (and time before that) where the words that came out of my mouth after "Python" were "is bullshit", but this year due to both AI jank and other unrelated tools having no path but Python, I've made my peace with it--and yeah it's spotty, though with Pylance I think it's fine, and it saves me from so many category errors that make old-Python infuriating.
Unfortunately for me, as an unreconstructed Ruby dork, Sorbet does not scratch the same itch. :(
Hate to break it to you but that's how all languages work. And if they don't they are just wasting CPU cycles checking types anywhere but the edges of the app.
