I make enough "trivial" errors that I find static typing useful on larger projects. Static vs dynamic typing in this context is mostly about when you catch the

I make enough "trivial" errors that I find static typing useful on larger projects. Static vs dynamic typing in this context is mostly about when you catch the bug, not "if" you'll catch it per se, so you're right that static doesn't necessarily mean fewer bugs. But it might still mean they're caught faster! Individual type errors have occasionally eaten a distressing amount of my time in dynamically typed languages - in terms of debug time and context switching, when I make the mistake of, say, trusting Javascript docs, in a way that mostly doesn't happen in statically typed languages IME. They help keep these trivial bugs trivial. Sadly most types systems (static or dynamic) aren't leveraged well enough to catch, say, SQL data being passed to things expecting SQL commands, so some issues still slip through. > Without a good unit test suite you are doomed in any language. I write a lot of code that is difficult to meaningfully unit test. How do I properly unit test a platform agnostic wrapper for gamepads - hook up a raspberry pi to some servos? How do I share that with our build server cluster? When is it a bug if nVidia and Intel GPUs render my scene slightly differently - what specific fuzzy conditions qualify as "bug" vs "expected variation"? How do I catch a missing memory barrier in multi-threaded code with unit tests? Sometimes an ARM processor with it's weaker memory semantics can help, but that still won't catch cases where triggering the bug requires the optimizer to do something specific. > Well, when you get your C++ program to compile, it is still probably wrong. While I agree in general, there are counterexamples. Even in the tire fire that is C++, static typing and compile time checks mean that if it still compiles, my rename refactoring in a large project was probably successful. If I rename something in Python, I have no such assurance, and probably updated the name where it was actually referencing something else, or failed to update the name where I thought it was referencing something else and it wasn't. So I have to test "everything". If I'm lucky, my manual audit of the codebase will show that this thing was only used by things that I know are well covered by unit tests. But let's be honest, I'm not that lucky.