To your first question: simply put, the easiest way was slipping in usage of Either<L, R> for handling “successful failure” states; error handling in Typescript

To your first question: simply put, the easiest way was slipping in usage of Either<L, R> for handling “successful failure” states; error handling in Typescript is still not fine grained enough, even with async functions (maybe even especially), so Either and Maybe/Option have been a big help. And once you have those, you might as well have them implement the same “interface”, and now you’re cooking with functors ;) No joke, it was error handling in successful promise resolves that made it an easy sell. I adore Reason — I use it extensively myself, but as I also adore OCaml this shouldn’t be surprising. The downside is that it’s a harder sell for a mostly backend team; it can definitely be used to great effect today, but Typescript for all its downsides is easier to use right now. Speaking of downsides: the major one with fp-ts (and io-ts) is some of the inscrutability of it’s more powerful abstractions for programmers who are not well versed in typed functional programming. But that’s okay: just don’t use them! You can get quite far with just the easy to understand concepts, and introduce things like EitherT or Task/IO and similar as the team becomes more confident with composing these data types!