> 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.
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?
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.