Our adoption of TypeScript led to a significant reduction in defects, and it definitely isn't killing productivity. Most of the time we take advantage of existing types so if anything it speeds things up in the long run.
You are misunderstanding what I mean. Through I haven't be to clear I think.
What I mean is code which not only uses types and takes advantage of the type system but overdoes it. In many languages with a powerful type system you can encode much more then just basic types and this is useful to reduce possible error cases. But if you overdo it the type system part becomes too complex, type error messages too unreadable and it hinders productivity and on-boarding.
I'm a big fan of static typing and believe that more encoding more constraints in the type system is _generally_ good. But if the resulting types become to complex it often not worth it.
I think I understand this one. I would restate it as "Powerful static type systems usually encode more constraints than you can easily reason about." And that's good(it catches your errors) and bad(you start to fight the compiler instead of solving the problem).
With simpler, more gradual designs like what are in Typescript or Haxe or even static, native-code languages like D, you have more escape hatches available, so you can iterate on the specification a few times and get code running quickly but also aim to make it tighter over time.
No what I mean is not that it encodes more constraints than you can reason about, but that the way some libraries abuses the type system to encode some of the constraints can cause more problems then it solves.
