It is hard to recommend Python in production

Idk why such noob stuff is upvoted on HN.<p>The only thing this tells you that you should try to avoid a billon nested loop iterations in python. In case you didnt know.<p>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&#x2F;ML. Are all the AI&#x2F;ML engineers just being stupid because their notebook could be faster if it was written in Rust? Of course not.<p>Clickbait title, garbage content.

Author started comparing a debian image&#x27;s size vs an alpine one. Immediately closed the article.

I am not saying the author&#x27;s remarks are not interesting, but they live in a vacuum. For most projects, the resources spent on the &quot;serving&quot; part of your web service are a small portion of the actual expenses. In many cases, it&#x27;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&#x27;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&#x27;s before using multithreading which really helps performance another order of magnitude.<p>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&#x27;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&#x27;t understand why management is so clueless as to not realize it.<p>Rust substantially raises the bar well beyond both Python and Go, but even in Rust, static analyzers are still necessary for acheiving maintainable code.

Bah, <a href="https:&#x2F;&#x2F;www.odoo.com" rel="nofollow">https:&#x2F;&#x2F;www.odoo.com</a> is opencore and fares pretty well. Go to github and you&#x27;ll find the code.

There&#x27;s a <i>lot</i> of Python users so this type of content will be hated. But of course it&#x27;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&#x27;re working on a project you don&#x27;t intend to grow, as it often turns out otherwise.

Depressing, since I used to like Python. Though I was always aware of the 100x slowdown (or cost increase) vs. C++.<p>PyPy isn&#x27;t much worse than Dart on this chart.<p>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.<p>I wonder where Swift would fit in?

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.