Type Safety Doesn’t Matter
I’m a huge believer in using strongly typed languages and leveraging type level protections in my codebases. But I’d like to clarify my new, somewhat modified stance on this:
What I mean is that, on its own, type safety is not important. It’s only useful because of what it accomplishes: moving errors from runtime to compile time. Even that isn’t a goal on its own. The real goal is reducing runtime errors. Type safety is one of the best methods of achieving these cascading goals, but it’s far from the only one.
This may sound pedantic and click-baity, but in my opinion it’s a vitally important distinction with real world ramifications. For example, when discussing architecture of code or reviewing a pull request, I will often times push back on changes that add more complexity in the type system. The reason is because, even if a change adds “type safety,” this extra complexity is only warranted if it achieves our primary goal, namely reducing runtime errors.
Such an assessment is largely speculative, subjective, and risk-based. By that last point, I’m tapping into my actuarial background. The idea is that, when considering a code change, the question will always be: do I think there’s a high likelihood that this change will meaningfully reduce bug count in the long term more so than other activities I could be spending this time on? And if you watched my talk the economic argument for functional programming (or read the slides ), you may be familiar with this way of thinking as the opportunity cost of spending more time on type safety.
