Not the OP, but most compilers for languages with static type systems are too slow for my taste. I have a workflow for writing lua programs in which I embed all of my tests in the same file that contains all of the runtime logic. Whenever that file changes, I have a monitor script that runs the program and validates my tests. This process typically happens in less than 20ms, so I've configured my editor to save my lua files whenever I type a single keystroke. It's like having a living REPL session that is persistently stored in the file.

When you develop in this style, you tend not to write type errors because you are constantly validating your program inputs and outputs, which the tight feedback loop encourages. Most statically typed languages have slow compilers. It is not uncommon for an incremental compile to take at least 1s, which is 50-100x slower than what I'm used to. Indeed, I find it distracting when compilation is that slow so with such a language I will still use a monitor script for iteration but I will manually save when I want validation. This means that I am not only getting slower feedback, I am getting less of it, which ultimately makes me less confident in my program. If I were making lots of type errors, maybe it would be worth it to have a type checker, but I'm generally not.

Sure, thanks for asking!

I think it's mostly about time to market and reduced total LOC.

I find that in strongly typed languages, frequently up to 30% or more of the total lines of code are dedicated to nothing but type satisfaction.

Sometimes this formalism is warranted, depending on the problem domain (banking, air craft systems, etc) but most of the time I find that the type systems are merely mental abstractions that are created to assist the developer in modeling the solution.

There's value in that.

As I've gained more experience, trivialities like the compiler catching junior programmer level silly type mistakes has become less valuable. Type systems don't address logic errors.

The flexibility of duck typing with loose contracts reduces total time to market for applications where that's a primary constraint.

This happens to be true in a vast class of problem domains, where having something quickly is more important than performance or formal correctness.

Since I tend to live in the startup space where TTM and MVPs are critical to business success, I'm inclined towards languages that support this.

I typically don't have to deal with large team coordination issues or extremely complex interdependence, and my systems are normally fairly basic - crud with business rules and a fancy UI.

In this case, things like type errors present themselves immediately in the UI and are easy to catch during development, reducing the value of compile time error detection.