[IceDane]

More than anything, this reveals your lack of understanding of modern languages and type systems.

TypeScript, for example, is one of the most widely used languages in the world. It has an incredibly powerful type system which you can use to model a lot of your invariants. By leaning on patterns such as correct-by-construction and branding, you can carry around type-level evidence that e.g. a number is within a certain range, or that the string you are carrying around is in fact a `UserId` and not just any other random string.

Can you intentionally break these guarantees if you go out of your way? Of course. But that's irrelevant, in the same way it is irrelevant that `any` can be used to break the type system guarantees. In practice, types are validated at the boundaries and everything inside can lean on those guarantees. The fact that someone can reach in and destroy those guarantees intentionally doesn't matter in practice.

[9rx]

Typescript is one of the actually-used languages that supports constraining the integer, albeit in a pretty awkward way.

    type Decade = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10

But now try defining a type that enforces a RFC-compliant email address...

There are languages with proper type systems that can define full contracts, but Typescript is not among them. Without that, you haven't really defined a usable contract as it pertains to the discussion here. You have to rely on testing to define the contract (e.g. assert the result of the 'generate email' function is RFC-complaint).

And Typescript most definitely does. Testing is central to a Typescript application. It may have one of the most advanced type systems found in languages actually used, but that type system is still much too incomplete to serve as the contract. Hence why the ecosystem is full of testing frameworks to help with defining the contract in tests.

[IceDane]

You clearly don't understand the patterns I described. Look up branding and try reading e.g. "parse, don't validate".