Python’s Weak Performance Matters

This was explicitly addressed in the article: as soon as you have to do anything which isn't a trivial numpy operation, performance goes off a cliff, and that can be a problem.

I haven't looked at it in a while, so I could be wrong, but I think with small enough programs you can still squeeze some payload into L1 in long tight loops where you're not jumping up and down the Python stack a lot.

But your overall point stands: if you're writing non-trivial Python programs your L1 is usually spent on language/runtime overhead.

"Python extensions I've written just use C/C++ data types and only occasionally passes python native types back to python."

See my other post; was your system basically using Python as an extension language on a system fundamentally implemented in C/C++? That's not the problem this discussion is about, which is when you have a large pile of Python code that is the main component of your system, and has proved to be slow. Piecemeal extensionization is not a very good option there, and non-piecemeal extensionization is "rewriting the system in a faster language".

If it's a lost art, it's because the domain where this is the best option is steadily shrinking. There's an increasing number of languages that interop well with C (and sometimes C++), are more convenient, and are still fast. Many of them are fast enough and convenient enough to simply implement your code in that language in the first place. As a result of that, I personally think that dynamic scripting languages have reached their peak and are now facing inexorable slow decline; the problem they solved in the 1990s is increasingly not a problem as a crop of languages that are both convenient and fast continue marching forward. JavaScript is, as ever, an exception due to its currently-privileged place in the browser ecosystem, though over the next decade that's going to fade as WebAssembly hits maturity.

(But let me emphasize that "slow"; I'm talking decades, not months. There is still plenty of opportunity to graduate this semester, get a job in dynamic scripting languages, and be in that space for 20 years. But I think in another 2-4 years we're all going to be able to agree they've peaked.)

To me the last sentence nullifies the entire argument. People doing a lot of numeric computations aren't (typically) doing it all in Python. They write critical sections in C (or some other "fast" language), or use existing libraries that already have done so. If they aren't writing those sections in C already, perhaps because they don't know how, or it would take too long to do right, then why would they ever choose to do the whole thing in C?

As a guy who just spent the past summer doing (his 19th year of) Python, (6rd year of) Cython(/Pyrex), and (8th year of) C, picking around PyPy, and writing a couple transpilers; the tools are incredible. And I think you're talking out your butt here.

Speed is a matter of choice and a bit of manual tooling. You seem like a Golang advocate; great. I hope it continues to work for you. Python solves 95% of problems today, and with the continued bettering of tooling (via PyPy, Cython, Pandas, SciPy, PyTorch, etc.), Python and the dozens of active member groups (individually with 100k+ global users) work independently in every niche with performance improvements until it takes the market. We embrace, extend, wrap, and improve.

I remember when Unladen Swallow was laid upon the laps of the CPython developers. That was a LLVM backend JIT for CPython (CPython had another JIT at the time, Psyco), combined with a collection of other improvements to the CPython runtime that Google laid on the CPython developer's laps. It was a patchset against an old (and unmaintained) version of CPython, and may have taken years of further development to merge back in. Meanwhile PyPy, Pyrex->Cython, etc., were all pretty solid, so the CPython devs left the Unlaiden Swallow, because it didn't seem worth it (I agree with them). See PEP 3146 for details.

But that doesn't mean CPython devs haven't been at it; what the heck do you think all of those "optional" type annotations are for in Python 3.x? Type checkers for one, compilers for two. Oh... yeah, we've been moving towards optional static type checkers and static compilation in the Python community for years; and as a community, you can basically piece it all together. Is it 100% yet? No, but it's a solid 95% for most use-cases.

Watching Golang over the years; it feels a lot like if it wasn't in Golang, it wasn't worth using with Go. I say this as a user of cgo from 2012-2013 in a failed attempt to make something in Golang + sockets + goroutines faster than the equivalent in Python + sockets + threads + C. But when I was seeing better performance in Python, better error reporting in Python, better C library wrapping in Python, and better tooling in Python - I went back to Python (funny how 20+ years of tooling will do that).

Don't get me wrong, I love the speed of the Golang compiler. It's just mostly everything else in the ecosystem I don't like; including the lack of a viable C/Golang interface for anything nontrivial (like leaving C threads running with references to Golang objects/structres), the hilariously short official documentation for cgo, the basic need to re-implement the world in Golang to get good performance, and still being subject to the whims of Rob Pike - whose bad decisions (in the form of Sawzall) already wasted a week of my life when I was at Google.

You want performance in Python? Okay. Where do you want performance? If there isn't already a library there to help you, I'd be very surprised.