Complicated types are effectively little Prolog programs, doing a bunch of very useful and helpful checks to make sure that your code does what you expect it to.
I do wish that Typescript would offer some tools to make it more ergonomic to write performant unifying code (I kind of despise conditional types, especially when you then use it to create the partially valid types by resolving to never). But I think it would also be very helpful to get people to understand that your types are their own little program that run and have performance characteristics. It's not magic!
There's been some handwaving about performance not being due to it running in JS (because at the end of the day unification is unification is unification and it takes time), but looking at the Typescript codebase in general and poking at it, I can't help but wonder how much of even the heavier stuff is "death by 1000 cuts" on that front.
This really was solidified by going through the course at https://type-level-typescript.com since it involves learning the type-level language of TypeScript and solve little puzzles. Doesn't really address performance much, but I think having a working-level understanding of what the type-checker is doing when it's "solving" your TypeScript type-level programs is an important prerequisite for having some intuition about type checker performance.
I use fp.ts quite a lot! I think it's _extremely unfortunate_ that the API docs don't include top-level examples for basically anything, though. So when people hit a problem that fp-ts or io-ts can solve, I have to basically write a disclaimer about the slight impenetrability before suggesting it.
I really think that TS itself should offer syntax more or less matching what that lib does at the type level, but this is a bit of a maximalist request.
It’s been a while since I looked deeply at them, but IIRC the primary difference is that io-ts returns Result types. It’s trivial to wrap that to produce a value or throw if that feels more comfortable.
It’s possible there are other aspects of the APIs that differ in meaningful ways, but last I checked virtually all of the libraries with similar functionality (and there are many) have roughly the same concepts until your schemas themselves get deeply complex.
I do wish that Typescript would offer some tools to make it more ergonomic to write performant unifying code (I kind of despise conditional types, especially when you then use it to create the partially valid types by resolving to never). But I think it would also be very helpful to get people to understand that your types are their own little program that run and have performance characteristics. It's not magic!
There's been some handwaving about performance not being due to it running in JS (because at the end of the day unification is unification is unification and it takes time), but looking at the Typescript codebase in general and poking at it, I can't help but wonder how much of even the heavier stuff is "death by 1000 cuts" on that front.