Python is so slow that I ironically don't care about performance improvement that much, because if you are writing any performance-sensitive part of your software in python you are screwed anyway, 50% faster code isn't going to help that much.
back
4 comments
Python is a joy to use and is used by a large number of apps as a tool of choice to get things done. Almost all of "retail" web crawling and machine learning in the world runs on Python.
In practice it is not slow at all. Plus the development iteration speed is probably second to none of all the programming languages.
If I would have my kid learn two programming languages it would be HTML and Python.
I never said that python is a bad language. In fact it is my favorite language and I probably have written more python code than any other language.
That has nothing to do with it being slow though. And as I said, all those machine learning code rely on numpy (which relies on LAPACK which is not written in python) or highly optimized cuda kernels (which again is not written in python).
Which is the optimal split! Write application/composing code in Python and highly performance sensitive parts in some FFI language (nowadays probably Rust?). It's not great if you do performance sensitive stuff all the time, but amazing if you just want to build something.
I understand and somehow agree with your point, however, it would also be nice for someone to have the ability to build something performant with a language like Python. But this is not really possible today, so the narrative that Python is for prototyping will keep holding.
> In practice it is not slow at all.
In practice, you're either not using Python (sleeping, while waiting for IO operations) or not using Python (C/Fortran/whatever libraries for heavier lifting: Pandas, numpy, PyTorch, etc).
I'd rather get things done in Go (or Rust). Better standard library, sane package management, dumb easy concurrency & parallelism, easy to distribute, compiles to a binary.
You spend far more time porting python libraries to rust when you can just use python for the vast majority of use cases.
is there a numpy for go? because numpy style numerics is table stakes for anything that replaces python.
I already knew about gonum. That's not numpy for go. Have you tried it? It's not really a replacement for numpy. And the API looks liek they barfed a bunch of line noise into the top-level namespace.
By the time I've typed in the code in https://www.gonum.org/post/intro_to_stats_with_gonum/, numpy already computed the mean.
Not a compelling repalcement. I spoke to the gonum developers when they first created it and told them they were wasting their time beceause the go leaders made their language intentionally be a "systems language", not a "scientific language".
Go is painfully verbose and Rust painfully complex compared to python.
Honestly, it feels inaccurate to call any modern programming language slow. Most are remarkably performant in the vast majority of cases. I’d be quick to yield that if your going for the bare minimum of latency, Python is likely not the right choice, but it feels a bit unfair to say Python is slow.
I will say that I agree with the sentiment of your comment: if your main focus is speed, you won’t be using Python, and if you’re using Python, you likely don’t care about speed.
> Most are remarkably performant in the vast majority of cases.
If your metric is based on execution time, then this might be true. Many programs are faster enough where the user doesn't care, or the impact on the overall execution time is slight.
But, if your metric is compared to other languages, this is measurably false [1]. Even Python emulated in the browser is faster than CPython in many cases [2]. And, this doesn't really give a complete picture, since many CPython libraries don't actually use Python, because pure python implementations of most anything are too slow. They use python as glue to call out to compiled libraries. But, this is also the main use case of CPython: glue for not Python.
1. Python always near the bottom. See other problems too: https://programming-language-benchmarks.vercel.app/problem/b...
2. Brython benchmarks: https://brython.info/speed_results.html
While I am a believer in writing performance sensitive code in performant programming languages, I would argue that it matters.
A lot of numerical software is Python glue code written around compiled kernels (written in C++, Rust, Fortran, etc) but the runtime of that glue code usually does impact the total runtime in a non-negligible way. So all wins are good to take.
Except when the algorithmic and data structure improvements to your program enabled by the high programming performance have better payoff than spending the time on low level optimizations on other stacks.