[MarquesMa]

> Static Typing reduces bugs.

This matches my experience. People say otherwise might need to put more effort on writing better tests.

That said static typing usually catch minor problems like typo faster. But for dynamic typing it's going to catch by tests a bit later. But usually tests run faster with dynamic languages, so it's a tradeoff.

My favorite approach is the mixed approach like TypeScript:

1. Faster feedback loops: Usually statically typed languages compiles slower thus slower feedback loops. But languages like TypeScript can skip type check and emit only to the runtime, making test watcher very fast - as soon as I hitting Cmd-S I can see the result.

2. Optional typing: Sometimes a function signature is going to be 10x larger than the body, which is really a hassle. Sometimes I just skip them, or skip typing module private functions as long as it's properly tested.

[why-el]

I like types, but I like types even more when they are at the edge of two systems and both systems understand them. For instance, in the past we ran Rails APIs and a lot of mobile apps consumed them, and there was a lot of math involved. We put Google's protocol buffers between them. The data's type info is thus shared. I liked this pattern a lot, and it did reduce A LOT of bugs (for instance ints vs floats).

Another thing: people working with dynamic typing often forget that often times they are interacting with a system with extreme opinions on types, namely their relational database, which is often times literally the heart of the business. If your language of choice has typing, you can sync that type info (smart ORMs, codegen), and thus reduce friction. With that said, I develop in Ruby and my understanding of where there might be "type friction and potential for bugs" has improved a lot over the years, so I don't mind the lack of types until we get optional typing sorted out.

[ehnto]

Why not have static typing and an IDE catch the issue before you run the test?