Very true, it is possible and practical, and chrono is a good example. But you can take a similar approach in dynamically typed languages as well. It wouldn't b

Very true, it is possible and practical, and chrono is a good example. But you can take a similar approach in dynamically typed languages as well. It wouldn't be hard to design a library that did something like this: some_duration = minutes(3) + seconds(2) Of course that doesn't change the fact that any function receiving a duration would only raise type errors at runtime. For instance, someone could try to pass the number of seconds as an integer rather than as a duration: remind_me_after(182) But any semantic testing would automatically catch type errors as well. remind_me_after would fail every single time assuming the implementation would be something like this: def remind_me_after(duration): reminder_api.set_reminder(now().as_seconds() + duration.as_seconds()) I think this is the reason why studies don't show huge differences in defects between dynamically and statically typed languages. You have to do semantic tests anyway, and they would cover most* type errors as well. What would it mean for code to be semantically correct while containing type errors? It would probably mean that the code is not in fact semantically correct because some semantic edge cases are not covered by the tests. * Not all of them because semantic tests could theoretically succeed by accident for some specific values that have incorrect types.