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

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.