“io-ts introduces the concept of a runtime type (an instance of the Type class) which represents a runtime validator for a typescript (static) type. [2]”
See:
[1] https://gcanti.github.io/io-ts/
[2] https://lorefnon.tech/u2018/03/25/typescript-and-validations...
In your code, if someone throws a bad class into the mix, it will blow up both in Typescript and in Java/C# and in any other programming language. But, somehow, blowing up in Typescript is way worse that blowing up in Java/C#. Go and tell me that when I'm not allowed to put `nulls` anywhere neither in Java nor in C#, because that's something I can do in Typescript today.
Even if it's only a compile time check, and can therefore still be circumvented at runtime, this check for null values has still helped me out a lot. At least within a class it ensures my assumptions are consistent, which is not nothing.
The problem with receiving a wrong class is not intrinsic to any particular type system:
A *a = reinterpret_cast<A*> &a;
// have a nice gdb day
>Typescript doesn't really add what it's supposed to add.
Underspecified/force-casted types couldn’t help with these promises. It is like programming in C with a heavy preference to void pointers and va_lists.
Anyway, we're going back to simple JSON objects. Typescript is clearly not helping in our case, and the whole process with parsing all incoming objects is fairly cumbersome without adding much value.