I realize there was another discussion about 2 years ago and the specifics of this post have largely been addressed. I will say that it's a pretty strong turn-

I realize there was another discussion about 2 years ago and the specifics of this post have largely been addressed. I will say that it's a pretty strong turn-off when somebody appears to be religiously aligned in their technical outlook. I'd rather talk to somebody who appreciates the pros and cons of static vs. dynamic typing and what the actual implications are. I don't want to talk to somebody who appears to only understand dynamic typing as a strawman and for whom higher-kinded/dependent static type systems are a crusade. I don't trust crusaders to make sound engineering recommendations, I want to talk to people who have a sober, well-reasoned, and experienced outlook on a subject. I like static type systems, I like compile-time type checking. That's not going to stop me using a dynamically typed language where it's appropriate. I'm going to loosely reiterate what Hickey has said on the matter: It's often the conceptual aspects of a problem that are difficult. The more quickly you can hammer out what exactly it is you need to do, the better off you are. Static type systems, as they currently exist in Haskell, Scala, OCaml, Agda, Epigram, Java, C#, C++, et al don't do a lot to help here. I'd rather chuck some Python/Clojure around until I know what it is exactly that I want, then start writing more rigid code. Part of why I like Clojure so much is that when an API or the "shape" of my problem becomes more clear after the REPL/experimentation stage, I can begin defining things in terms of protocols or interfaces. What's most interesting to me about this is that the protocols are largely typeclasses which Go's interfaces resemble. You get the same basic expressive power but there are better affordances for the conceptual stage and a greater breadth of how firm/rigid your code is. Part of my problem with static type systems is that they are often an all-or-nothing proposition (disabled type-checking/type holes/undefined not-withstanding, to avert the inevitable cascade of GHC-extension-(ab)using Haskell users). To summarize: It's a progression where your code becomes more concrete and final over time as you better understand the problem. Dynamic type systems that are well-designed suit this model very well. Static type systems are better for performance and for situations where the problem is well-defined and you're mostly satisfying an engineering problem rather than exploring a conceptual one that's subject to change. Side note/anecdote: We use Python prolifically at my day job, what few type errors that occur are usually related to None and not the general type errors that static-type-users tend to suppose happens on a regular basis. Amusingly, C++, Java, and C# are all subject to this same issue. We've been cleaning it up over time by using imitations of monads/monoids.