(…continuing a Twitter thread)
io-ts caught my attention a while back and I finally had the chance to read through it. I’m glad folks are experimenting in this area, particularly with the potential reach into multiple communities and ecosystems that TypeScript affords.
We use dry-rb extensively at work and I was curious how a TypeScript expression of the same idea (define type-like structures at your runtime boundaries) looks.
The flippant response to runtime type systems for dynamic languages is: if you love types so much, why aren’t you using Haskell, Scala, Swift, etc.? That is, a type system over JavaScript or Ruby is a relatively new/unconventional choice.
Gradual type checkers: it works for Facebook and Stripe. Maybe it scales down for much smaller teams and codebases? Weird flex, but okay.
In reality, a runtime type system is easy to adopt and, when paired with some kind of Either/Result abstraction, can be built incrementally by composing types, data coercions to types, and validations of coerced data.
Having spent a year and change working with dry-rb’s runtime types/validations, I’m looking forward to introducing Sorbet. I like the idea of writing types and function signatures for development-time enforcement, but having the option to use some of them at runtime for boundary enforcement.
dry-rb has served us well, but the development experience that I crafted is highly coupled to using a Result/monad-ish idiom. Lots of combinator-envy. Most developers don’t crave this sort of thing.
Even if it’s successfully sold, it’s an uphill battle of education and FP/OO adaptation the whole way. If I were doing it over I’d look to Go’s tedious but easy to teach idiom of checking for errors after nearly every non-trivial operation.
I think dry-rb and io-ts will succeed or fail in very similar ways. Teams that know an ML-like language but are for some reason using JS or Ruby will take quickly to it. Otherwise, there’s an impedance mismatch to manage as they teams their own idioms on top of runtime types.
I’d pitch this to front-end developers as similar to React’s PropTypes, but better.
PropTypes give you greater confidence that you’re passing the right properties to a component and that a refactoring didn’t break things. Type-asserting data structures, like io-ts, give you confidence that the boundaries of your system, e.g. the XHR request/responses and persisting data to local storage, are either well-formed or immediately kick over to failure handling.
Enforcing object shapes (keys and nesting), type correctness (the value for key X is type Y), and validity (values declared as an “age” are always positive integers) at the boundary of your application and between components means you can more code on the “happy path” in your application logic. Conditionals and error handling are largely, but not entirely, pushed outwards to prop types or the boundary type system. This is, in my opinion, living the dream!
The gift and the curse of io-ts and dry-rb’s design is the use of combinators as the center of their design.
The skill ceiling for composing functions to handle network/database requests, type/shape assertions, coercions, and validations is very high. There’s lots to learn about combinators and the more you know, the more you can do. The downside is that the skill floor is also high. The less you know about combinators, the more mysterious, intimidating, and math-y they are.
It’s an unfortunate reality that developers rarely rave about how great a library or language’s error model is. Mostly people put up with exception handling and try to live in a blissful world of error-avoidance and happy paths.
Result types - e.g. Rust’s Result, io-ts’ Either, Haskell’s monads, dry-rb’s Result and monads, Elm’s Result and Maybe - are promising. Function return types that are explicit about whether the thing succeeded or failed (without stack manipulation hijinks) is something we really should have put in practice some time ago. io-ts and dry-rb are existence proofs, to me, that you don’t need an extremely sophisticated type system to make these work in practical, runtime-typed languages like Python, Ruby, or JavaScript. But they can quickly send you down the road of combinators. I’ve found this is not a road developers are enthusiastic about traveling.
Go and Erlang take a different, utterly unsophisticated, road and I wonder if it’s more promising. Functions that can fail (any kind of IO, some kinds of math, etc.) return a success value and error value as an array or tuple. Developers are expected to always check for an error before proceeding; linters and peers will complain if you don’t.
If a linter does it, so can a compiler or gradual type system can too. Maybe the middle ground between the status quo of exceptions and the promised land of result types is compiler-enforced checking of success/error pairs. The advantage is, no invention or re-learning is needed. It’s an array and a conditional. Granted, I’d prefer to get rid of the conditional. But, I’ll take the ease of training developers on the approach as a trade-off.
In short: my new hypothesis is “run-time enforcement of types/values/rules around the boundaries of your system, gradual/static types inside your system to prevent programmer errors”. If you can go further and use a static type system like Rust or Elm to reach the point your software is “correct by design”, that seems like living the mega-dream. 🌈
