> 1. Static type checkers increase compile times. It should be noted that this potential impact on compile times amount to a few seconds. > 2. If you're build

> 1. Static type checkers increase compile times. It should be noted that this potential impact on compile times amount to a few seconds. > 2. If you're building a system which has to interact with other systems a lot, static types can be a hindrance if your static type system and their type system don't agree on fundamental things like how data should be modelled. I fail to understand how failing to comply with a contract is a type checking problem, and one which goes away if you no longer perform validations. > 3. Static type checkers can have bugs or quirky behaviour. This can lead to a lot of wasted time, and/or inelegant workarounds that makes your code less understandable (and therefore, more likely to have bugs in the future). I'm not sure if your example is valid, as in your blog you quite openly state that the root cause of your bug was your failure to specify the right return type. You can't really fault a system by complying with the definition you've provided. > 4. It's surprisingly hard to find any research that can demonstrate that static type checkers actually lead to fewer bugs. A quick search in Google Scholar for "static type bugs" popped about 4k search hits, the first of which is an article on quantifying detectable bugs on javascript which states that switching to typescript allowed 15% of public bugs to be detected.