4 ms·

It is hard to recommend Python in production

33 points by ashishb 2y ago

musicale 2y ago
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?
- ashishb 2y ago
  > 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 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/ 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.
- MonstraG 2y ago
  Oh no it's the bouncy ball chart. Please, if you have enough time, watch this https://youtu.be/EH12jHkQFQk https://youtu.be/EH12jHkQFQk and avoid making any decisions using this chart.
  - raverbashing 2y ago
    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
    - ashishb 2y ago
      > "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.
      - raverbashing 2y ago
        > 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
        ashishb 2y ago
        Why do I have to restrict myself to interpreted languages only?
  - ashishb 2y ago
    > 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.
darthrupert 2y ago
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.
- randomNumber7 2y ago
  Now that AI based verification exists, I can just write C again and call it a day.
  - darthrupert 2y ago
    That's false even as a joke. C is less safe than either of python or Rust and has no benefits against Rust.
    - ashishb 2y ago
      > C is less safe than either of python or Rust and has no benefits against Rust. Indeed.
  - timeon 2y ago
    I wonder if Rust or C would decrease need for power use while training those models.
    - ashishb 2y ago
      It definitely will. Whether it will make a noticable difference depends on how much non-cuda work happens in model training.
randomNumber7 2y ago
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.
- ashishb 2y ago
  > 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.
  - ashishb 2y ago
    > 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.
    - andag 2y ago
      ... Adding a step in CICD that catches this is extremely trivial though.
      - ashishb 2y ago
        Which tools would you recommend for that?
- isucksdecock 2y ago
  [flagged]
  - 2y ago
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
odie5533 2y ago
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.
- ashishb 2y ago
  > 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.
  - user32489318 2y ago
    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.
    - ashishb 2y ago
      Indeed. Pure data manipulation, especially, when it being done for a batch job, is a good use case for Python.
lordkrandel 2y ago
Bah, https://www.odoo.com https://www.odoo.com is opencore and fares pretty well. Go to github and you'll find the code.
- ashishb 2y ago
  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.
laurent_du 2y ago
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.
- ashishb 2y ago
  > 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++.
  - laurent_du 2y ago
    I agree with you that for such an application, Python is probably not the right fit.
0xCAP 2y ago
Author started comparing a debian image's size vs an alpine one. Immediately closed the article.
- ashishb 2y ago
  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).
OutOfHere 2y ago
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.
- ashishb 2y ago
  That's my experience as well.
BuckRogers 2y ago
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.
throwask 2y ago
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.

33 points by ashishb 2y ago

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?

ashishb 2y ago
> 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 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/ 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.
MonstraG 2y ago
Oh no it's the bouncy ball chart. Please, if you have enough time, watch this https://youtu.be/EH12jHkQFQk https://youtu.be/EH12jHkQFQk and avoid making any decisions using this chart.
- raverbashing 2y ago
  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
  - ashishb 2y ago
    > "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.
    - raverbashing 2y ago
      > 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
      - ashishb 2y ago
        Why do I have to restrict myself to interpreted languages only?
- ashishb 2y ago
  > 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.

darthrupert 2y ago

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.

randomNumber7 2y ago
Now that AI based verification exists, I can just write C again and call it a day.
- darthrupert 2y ago
  That's false even as a joke. C is less safe than either of python or Rust and has no benefits against Rust.
  - ashishb 2y ago
    > C is less safe than either of python or Rust and has no benefits against Rust. Indeed.
- timeon 2y ago
  I wonder if Rust or C would decrease need for power use while training those models.
  - ashishb 2y ago
    It definitely will. Whether it will make a noticable difference depends on how much non-cuda work happens in model training.

randomNumber7 2y ago

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.

ashishb 2y ago
> 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.
- ashishb 2y ago
  > 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.
  - andag 2y ago
    ... Adding a step in CICD that catches this is extremely trivial though.
    - ashishb 2y ago
      Which tools would you recommend for that?
isucksdecock 2y ago
[flagged]
- 2y ago

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

odie5533 2y ago

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.

ashishb 2y ago
> 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.
- user32489318 2y ago
  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.
  - ashishb 2y ago
    Indeed. Pure data manipulation, especially, when it being done for a batch job, is a good use case for Python.

lordkrandel 2y ago

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

ashishb 2y ago
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.

laurent_du 2y ago

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.

ashishb 2y ago
> 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++.
- laurent_du 2y ago
  I agree with you that for such an application, Python is probably not the right fit.

0xCAP 2y ago

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

ashishb 2y ago
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).

OutOfHere 2y ago

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.

ashishb 2y ago
That's my experience as well.

BuckRogers 2y ago

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.

throwask 2y ago

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.