The big difference is that there are tools that allow automatic and guaranteed safe refactors for such languages. For instance, I can't guarantee that something as simple as renaming a method won't cause runtime errors in a dynamic language.

Agreed, and I would not claim it makes no difference, just that it eliminates only one category of brittleness from a project.

Others — poor testing, over-coupling, external dependencies, and the broad category of anti-patterns — are still available to us.

In type safe languages your tools can do refactorings like extract class/extract interface (reduce coupling), create mocks automatically based on type information (helps testing), etc.

Why not let the compiler eliminate a whole class of problems and let the automated tools help you with guaranteed safe refactors?

I get both of these in python (extract class is provided by a good idea, and `mock.Mock(OBJECT_TO_MOCK, autospec=True)` creates a mock object which raises an exception if called incorrectly and can do a lot of other powerful things.

Until you try to mock anything related to the boto3 library provided by AWS....

All of the functionality is something like....

s3client = boto3.resource("s3")

The IDE has no idea what s3client is. Since I've just started using Python and mostly to do things with AWS, is this considered "Pythonic"?

Btw, After using PHP, Perl, and JavaScript, and forever hating dynamic languages, Python made me change my mind. I love Python for simple scripts that interact with AWS and event based AWS lambdas.

My Python IDE handles all the "rename a function" burden for me.

yeah, trivial annoyances like

   AttributeError: 'NoneType' object has no attribute 'method'

when you just don't expect it.

Right - this trivial annoyance, the Python equivalent of a NullPointerException, is not actually prevented by the static type system in Java and some other popular static languages. (Kotlin does prevent it, though!)

Just to clarify, I'm using trivial here in the technical sense.

YMMV on what counts as trivial to you, of course, after three days straight tearing your hair out!

If your type system only prevents trivial errors then it's not sufficiently 'strong'.

"Just as possible" is a pretty strong claim, given you're effectively saying that types have no effect on brittleness or contrarily, robustness.