Hi Anthony, thank you, this is a nice overview of the trade-offs. I have to say, though, I’m a little surprised by the conclusion. JavaScript is similarly dynamic and yet is something like 5x faster than CPython, so there is something else going on.

I attribute the slowness, ironically, to NumPy and SciPy: they are hugely valuable packages which are closely tied to the CPython API. This means changing the API to support a JIT or modern garbage collector to be added loses a huge chunk of the ecosystem may people consider part of Python. Thus, PyPy, Jython (run on JVM), and IronPython (run on .NET CLR) are all faster than CPython but have very little up-take because to many “Python” means “Python + NumPy + SciPy” and all of the rest of the ecosystem. And, in my personal experience, many of the rest are concerned with the startup time you mentioned, not runtime.

Which maybe is what you are referring to by versatility: Python is trying to serve number crunching duties as an alternate to R or Julia or static languages, as well as scripting duties comparing to Bash, Tcl, and Perl.