It is hard to recommend Python in production

Depressing, since I used to like Python. Though I was always aware of the 100x slowdown (or cost increase) vs. C++.

PyPy isn't much worse than Dart on this chart.

The interesting bit to me is JavaScript giving Go a run for its money. To me this indicates that Python could be a lot faster than it is.

I wonder where Swift would fit in?

> Depressing, since I used to like Python

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.

I took the chart from here https://benjdd.com/languages/, it does a very specific test of loop iterations.

If you look at concurrency, I am sure Go will do way better than Node JS for concurrent request handling.

Oh no it's the bouncy ball chart.

Please, if you have enough time, watch this https://youtu.be/EH12jHkQFQk

and avoid making any decisions using this chart.

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.

Honestly yeah

It's an artificial benchmark that means nothing in production

Also the article does not bring much to the table except of python whining

"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

Now that AI based verification exists, I can just write C again and call it a day.

Idk why such noob stuff is upvoted on HN.

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.

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.

Clickbait title, garbage content.

> The only thing this tells you that you should try to avoid a billon nested loop iterations in python. In case you didnt know.

Where does the article talk about the billion nested loop at all? It uses that as an illustration.

I mentioned the problems related to speed and performance of a simple web server as well as code maintainability issues.

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

> and avoid making any decisions using this chart.

I did not mention that chart at all in the blog post. I just used this as a nice illustration.

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

That's false even as a joke. C is less safe than either of python or Rust and has no benefits against Rust.

> C is less safe than either of python or Rust and has no benefits against Rust.

Indeed.

Bah, https://www.odoo.com is opencore and fares pretty well. Go to github and you'll find the code.

Yeah, you can write Python in production. I, myself, have done that a lot. I don't think it is my preferred choice in 2025 though.

> But I have never really worked with pythons type extension so nowadays even this might be good enough.

I have used Python type system extensively, it is unfortunately, still an honor-code based system. So, you have to catch it during code reviews.

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.

Indeed. Pure data manipulation, especially, when it being done for a batch job, is a good use case for Python.

... Adding a step in CICD that catches this is extremely trivial though.

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.

I wonder if Rust or C would decrease need for power use while training those models.

Author started comparing a debian image's size vs an alpine one. Immediately closed the article.

> If I did that with Node, you would say what about Ruby.

No, because the comparison here is runtimes of interpreted languages

Comparing a compiled binary to the python/node/ruby runtime is comparing Apples to Oranges

Which tools would you recommend for that?

Python alpine images are useless for any non-trivial project.

> Author started comparing a debian image's size vs an alpine one. Immediately closed the article.

I did not compare Debian to Alpine. I compared Debian to a scratch image (for Go).

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.

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

That's my experience as well.

Why do I have to restrict myself to interpreted languages only?

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.

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.

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.

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.

The article did talk about maintainability issues with Python as well.

I agree with you that for such an application, Python is probably not the right fit.

It definitely will. Whether it will make a noticable difference depends on how much non-cuda work happens in model training.