Problem
dry-types and Sorbet both independently solve the problem of runtime type checking. Both are able to allow for type assertions at runtime in their own way. However, there are some major pros and cons to each one.
Pros + Cons
| dry-types | sorbet-runtime |
|---|---|
| + nicer api | + sigs allow for static checks |
| + already widely adopted | - T::Struct is not as nice as Dry::Struct (worse API) |
| + offers advanced functionality | - runtime checks are too simple (i.e. can’t define coercions, or other constraints) |
| - does not allow for static type checking | + lots of momentum, being adopted at Stripe + Shopify |
What do we do?
I think we need to address the issue, and see if there is a way to make dry + sorbet play nicely together. Otherwise, users will be left with a choice:
Should I use dry-types or Sorbet on this project? Managing two sets of type declarations is too much overhead.
Let’s see if we can come up with a way to make Sorbet infer static information from dry-types in a smooth way, so no one ever has to choose between dry or sorbet. 