> With haskell, for example, that comes at the expense of development velocity and performance (or at least, the ability to reason about performance). The (dep

> With haskell, for example, that comes at the expense of development velocity and performance (or at least, the ability to reason about performance). The (depending on perspective) weaker ability to reason about performance in Haskell stems from laziness, which itself has nothing to do with type systems. It's clashes with side-effects are solved _via_ the type system (The IO type). Regarding development velocity: _The developers_ are choosing how much time they spent on proving things to the type checker. Sure, writing a function that requires of its argument the type { n % 2 == 0 } or something is more labor intensive than just using Int and runtime panicking on invalid values. But you can choose do just that instead! There is no decree that on has to be as precise in their types as possible, no matter how much a given type system is able to express.