The only thing this tells you that you should try to avoid a billon nested loop iterations in python. In case you didnt know.
On the other hand I would also see python as a bit questionable for bigger procejts, just because at some point a type system does more help than harm. But I have never really worked with pythons type extension so nowadays even this might be good enough.
I'd argue it's noob to use Python for anything other than where it has actual strengths like data science. Even AI can't help Python performance issues, you're stuck. AI can help verify C code, for example, is memory safe. There's just nothing you can do to fix Python's biggest problems. Wrong tool for the job.
Most people seem to agree with my "hot" takes. Why should I invest so much time for a random comment? I just clarified what are the limits of my opinion.
On the other hand it doesn't seem you read the article? It is mostly focused on performance, which often shouldnt be the main focus when selecting the language. And even if you need performance (e.g. data science) it can be very fast if you source out the billion iterations to a library.
What does Python in production even mean? Python is used extensively in AI/ML. Are all the AI/ML engineers just being stupid because their notebook could be faster if it was written in Rust? Of course not.
> Are all the AI/ML engineers just being stupid because their notebook could be faster if it was written in Rust
I think Python is a great language for running inside Notebooks.
Running non-AI/ML jobs in production is where Python brings more downsides than
upsides.
Depends on the setting. I have built python ETL pipelines for some of my customers, it’s slow, not efficient but, every data scientist can read the code and make it work for their changing requirements.
At the end of the day, if you’re running a 3hour etl job in Python or 1h on a Spark/hive/mapReduce/what else legacy tooling they got I’d choose 3H one if team can support it and is not afraid to make changes.
I am not saying the author's remarks are not interesting, but they live in a vacuum. For most projects, the resources spent on the "serving" part of your web service are a small portion of the actual expenses. In many cases, it's going to be less than 1%. Going from 0.1% to 0.01% is not a significant improvement.
A typical Django-based application has a lot of non Python code that is running separately and the performance of Django or Python itself are mostly irrelevant.
If your application is a TODO app and you have billions of users, maybe yeah.
> A typical Django-based application has a lot of non Python code that is running separately and the performance of Django or Python itself are mostly irrelevant.
I have seen applications where this serving cost alone becomes dominant.
And that's why I shared the YouTube story as well where the ~60X savings came from migrating from Python -> C++.
I've found that porting a python script to go that did some basic web requests in a loop reduced the errors and increased performance greatly. That's before using multithreading which really helps performance another order of magnitude.
However for a database-backed web app? The argument on HN has always been productivity wins by helping you to grow your startup more quickly. I myself would prefer a compiled language that also has memory safety.
Python codebases in industry accumulate tech debt extremely fast in practice. It doesn't have to be this way, but most Python developers in industry lack both the basic discipline and the static analyzer tooling to avoid mountains of tech debt. Once you take the lead developer out of the equation, the project immediately collapses under its debt. I don't understand why management is so clueless as to not realize it.
Rust substantially raises the bar well beyond both Python and Go, but even in Rust, static analyzers are still necessary for acheiving maintainable code.
There's a lot of Python users so this type of content will be hated. But of course it's right. I would reach for C# every single time on every single project. Java is never a mistake either. You should use industrial strength languages on industrial strength platforms with industrial strength tooling. It makes no sense not to use something intended to grow to 1MLOC+. Even if you're working on a project you don't intend to grow, as it often turns out otherwise.
> "Oh the Go dockerfile is smaller" Yes you compiled it and is running a binary. Big woop. Funny how the author not doing the same comparison with node
If I did that with Node, you would say what about Ruby.
If I did that with Ruby, you would say what about Zig.
There is no end to the list of languages.
> It's an artificial benchmark that means nothing in production
It was a cover illustration, I did not mention that at all.
In fact, I demonstrated the resource consumption of Python's docker image.
If you have suggestions to make the Python one, I am all ears.
I used to love Python.
In fact, I still maintain a fairly popular Android development tool written in Python https://github.com/ashishb/adb-enhanced
Over time, my love has hit a reality check.
Now that Rust exists and llm can easily lift a more junior person over the initially difficult parts, there are not many things you should use python for.
The only thing this tells you that you should try to avoid a billon nested loop iterations in python. In case you didnt know.
On the other hand I would also see python as a bit questionable for bigger procejts, just because at some point a type system does more help than harm. But I have never really worked with pythons type extension so nowadays even this might be good enough.