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