> Statically typed languages create a lot of complexity from being entirely dependent on types being correct in a static sense rather than at runtime.

Python’s type annotations aren’t checked at runtime, though - they’re also entirely static. So you either have to:

- Write code that’s as pedantically correct as in a traditional statically-typed language (e.g. by using `mypy —-strict`), in which case you’d be better off using a language that supports AOT-compilation, or

- Be prepared for cases where the runtime type doesn’t match the annotation. This is unacceptable - I hate the idea of code that tells lies.

You're entirely forgetting the benefits.

1) Scientists, hobbyists etc. can be super productive with Python while disregarding types.

2) Software developers can write serious applications with type checking.

Statically typed languages exclude group that benefit from 1).

A language that tries to satisfy both of these groups won’t be ideal for either of them.

Python should aim to be perfect for group 1. There are many other languages that will always be a better choice for group 2.

I disagree. You can spend 90% of your time doing e.g. data science, and then one day you need to integrate with a DB or make a cross-platform desktop GUI application, as an example. Should you learn C++ (it takes a decade to become a very mediocre C++-developer), or Java to write a desktop GUI application?

No, there isn't "always" a better choice for group 2.

- Most software isn't CPU bound, so that defies "always" in your argument

- You need libraries get things done

What language would you always pick for group 2? Or would you pick a different one for each task, spending an order of magnitude more time learning them?

> Statically typed languages create a lot of complexity from being entirely dependent on types being correct in a static sense rather than at runtime.

Nonsense. It's very easy to use a runtime cast if and when you want to, even in Haskell. You're in control of exactly where typechecking doesn't happen.

In contrast, in a dynamic language with optional typechecking you have basically no guarantees. Even if 99% of your codebase is typechecked, you have no idea what errors might be lurking in the other 1% or how far they might propagate, since a type error can show up essentially arbitrarily far away from its actual cause. It's the worst of both worlds - you pay all the costs of a static type system but get hardly any of the benefits.

I think this is a pretty old-school mindset. For instance, with strict TypeScript the overhead once you get used to properly typing things is minimal - most things are inferred, and it actually empowers you to code faster as you have guard rails and great autocomplete; the issues are more likely due to poor/non-existent types.