Comment by addaon
> we want code that's expressive enough to do what we want, while being constrained enough to not do what we don't
I don't think that's an ideal mental model. Code in any (useful) language can do what you want, and can not do what you don't want. The question is how far that code is from code that breaks those properties -- using a distance measure that takes into account likelihood of a given defect being written by a coder, passing code review, being missed in testing, etc. (Which is a key point -- the distance metric changes with your quality processes! The ideal language for a person writing on their own with maybe some unit testing is not the same as for a team with rigorous quality processes.) Static typing is not about making correct code better, it's about making incorrect code more likely to be detected earlier in the process (by you, not your customers).
Everything has a cost. If you had to pick between "write 99% correct code in 1 week" vs "write 100% correct code in 1 year", you probably would pick the former, and just solve the 1% as you go. It's an absurd hypothetical, but illustrates that it's not just about correctness. Cost matters.
What often annoys me about proponents of static typing is that they sound like it doesn't have a cost. But it does.
1. It makes syntax more verbose, harder to see the "story" among the "metadata".
2. It makes code less composable, meaning that everything requires complex interfaces to support everything else.
3. It encourages reuse of fewer general types across the codebase, vs narrow scoped situational ones.
4. It optimizes for "everything must be protected from everything" mentality, when in reality you only have like 2-5 possible data entries into your system.
5. It makes tests more complex to write.
6. Compiled languages are less likely to give you a powerful/practical REPL in a live environment.
For some, this loses more than it gains.
Also, albeit I haven't seen this studied, human factor probably plays bigger role here than we realize. Too many road signs ironically make roads less safe due to distraction. When my code looks simple and small, my brain gets to focus better on "what can go wrong specifically here". When the language demands I spend my attention constructing types, and add more and more noise, it leaves me less energy and perspective on just taking a step back and thinking "what's actually happening here".