> But then I remember that Python is dog slow compared to other languages with comparable ergonomics and first-class support for static typing, and...idk it's a tough sell.
Post like these aptly describe why companies are downsizing in lieu of AI assistants, and they are not wrong for doing so.
Yes, Python is "slow". The thing is, compute is cheap these days and development time is expensive. $1000 per month is considered expensive as hell for an EC2 instance, but no developer would work for $12000 a year.
Furthermore, in modern software dev, most of the bottlenecks is network latency. If your total end to end operation takes 200ms mostly because of network calls, it doesn't matter if you code runs in 10 ms or 5ms as far as compute goes.
When it comes to development, the biggest uses of time are
1. Interfacing with some API or tool, for which you have to write code 2. Making a change, testing a change, fixing bugs.
Python has both covered better than any other language. Just today, it took me literally 10 mins to write code for a menu bar for my Mac using rumps python library so I have most commonly used commands available without typing into a terminal, and that is without using an LLM. Go ahead and try to do the same in Java or Rust or C++ and I promise you that unless you have experience with Mac development, its going to take you way more time. Python has additional things like just putting breakpoint() where you want the debugger, jupyter notebooks for prototyping, and things like lazy imports where you use import inside a function so large modules only get loaded when they run. No compilation step, no complex syntax. Multiprocessing is very easy to use as a replacement for threading, really dunno why people want to get rid of GIL so much. Functionally the only difference is overhead in launching a thread vs launching a process, and shared memory. But with multiprocessing API, you simply spin up a worker pool and send data over Pipes, and its pretty much just as fast as multithreading.
In the end, the things that matter are results. If LLMs can produce code that works, no matter how stringy it is, that code can run in production and start making company money, while they don't have to pay you money for multiple months to write the code yourself. Likewise, if you are able to develop things fast, and a company has to spend a bit more on compute, its a no brainer on using Python.
Meanwhile like strong typing, speed, GIL, and other popular things that get mentioned is all just echos of bullshit education that you learned in CS, and people repeat them without actually having any real world experience. So what if you have weak typing and make mistakes - code fails to run or generate correct results, you go and fix the code, and problem solved. People act like failing code makes your computer explode or something. There is no functional difference between a compilation failure and a code running failure. And as far as production goes, there has never been a case of a strong type language that gets used that gets deployed and doesn't have any bugs, because those bugs are all logic bugs within the actual code. And consequently, with Python, its way easier to fix those bugs.
Youtube, Uber, and a bunch of other well used services all run Python backends for a good reason. And now with skilled LLM usage, a single developer can write services in days that would take a team of engineers to write in weeks.
So TL:DR, if you actually want to stay competitive, use Python. The next set of LLMs are all going to be highly specialized smaller models, and being able to integrate them into services with Pytorch is going to be a very valuable skill, and nobody who is hiring will give a shit how memory safe Rust is.
I write Python all day for work and I run into its issues all the time, be it performance or weak typing or just lack of modern language features. If you’re just vibecoding all day and that’s ok for what you want it to do, all the more power to you, but do at least take a moment to understand that when people want things you see no value in maybe they just have different requirements than you do.
Notice how you start your reply with a personal experience? Thats the big difference between what people say, and what I say. Its not about misunderstanding. You can't find a single flaw in what I said, so your only reply is "well in my experience Python sucks".
So its a you problem, not a python problem.
Strong typing doesn't make code better. Proof = Linux system is written in C, without strong typing (unless you consider basic types strong typing), and it works. Good developers make code good. While bad developers make bad code in strongly typed languages.
Python doesn't lack modern language features. It potentially lacks things that you may like, but you aren't the authority on modern language features.
If you are writing code that needs to run fast, of courses Python is a poor choice. But its likely that only a portion of your code needs to run fast, at which point you can easily use python native code interfaces, or even easier, compile a small binary written in C, and launch that from Python.
You argued that people who disagree with you lack real-world experience, then when I give you mine you turn around and call me out for it? It's possible that my concerns are a "me" problem but your problem seems that you forgot what I was replying to.
In my experience, Python is often bad for the things I have needed it for, which includes PyTorch just FYI even though I think it's patently absurd that people running the coding models of the future are going to be directly talking to PyTorch. You claim that this is because I am up on my ivory tower, and that I am not an authority on language design. Those might be true. But you most definitely are not an authority on software engineering or language design either, and your statements can only leave one with the conclusion that you have never thought deeply at the examples you're pulling out. There is a huge difference between bugs that are caught during development and those that are found out "in the wild", including the fact that sometimes you don't even get to fix things after they have shipped. In fact in a past life we were bitten by trivial bugs in the Linux kernel all the time where we found it did not in fact work but the code had already been deployed to a hundred million phones in Asia that were never going to be updated. I think the fact that we had a few dozen very good people on staff to resolve the issues caused by simple bugs that strongly typed languages make difficult is a bad place to be, actually.
The irony here is UV is written in Rust.
That's not exactly for slowness reasons. The creators of uv have stated that if pip followed the same algorithms they'd see similar performance benefits. People greatly overstate the Python performance penalty.
... Actually, could you show me where they said it? I've been explaining it from first principles from a while now and it would be nice to be able to go "but don't take my word for it" as well.
(Python does incur a hefty performance penalty for things that are actually CPU bound. But that doesn't describe most of the process of installing Python packages; and the main part that is CPU bound is implemented by CPython in C.)
Python is bad for large projects, and it's not just because of speed.
I see it shine for scripts and AI but that's it.
Do you not consider Youtube or Uber large projects?
>$1000 per month is considered expensive as hell for an EC2 instance, but no developer would work for $12000 a year.
If using Python instead of what we use, our cloud costs would be more than double.
And I can't go to CEO and CFO and explain to them that I want to double the cloud costs (which are already seen as high).
Then, our development speed won't really improve because we have large projects.
That being said, I think using Python for scripting is great in our case.
>If using Python instead of what we use, our cloud costs would be more than double.
You won't double your costs and I can safely say that without knowing anything about your service. Because if you use PyPy, the speed up is generally 2x. So right there, your argument is defeated.
But even without PyPy, I am willing to bet that your service has a dominant component of either network calls, or data processing. In the former case, you can use Python with things like uvloop and multiprocessing to basically structure your service so that you are filling the processing time with waiting for network calls, spending minimal time in actual compute, which means you don't get any slower. In the latter case, its pretty straightforward to write a data cruncher in a more optimized language like C and run it from Python - even if you don't wanna deal with native interfaces, an LLM can write you a small udp server that can listen on a unix pipe for messages to process, and from python you just launch it with subprocess and send data to it.
So unless you run a highly specialized service with a very niche use case, you would be absolutely fine with Python.
And even then, Im willing to bet based on average use case that your cloud costs aren't even close to optimal. In the case of AWS, so many companies use managed services like Dynamo DB when they could easily run a reserved small EC2 instance and run their own version of Mongo or something similar. At my current company, the only AWS services we use is S3 and EC2, where things like database software or caching software is all manually installed and ran on EC2. If you know what you are doing, its not really that hard to manage. We even have or own version of AWS Lambda.
[flagged]
Don't you know most slow things are only from apis! /s
For someone writing a whole essay why python's speed is not a problem, one would expect to have worked in workloads where performance actually matters. For most people in this industry, that would be web APIs. Though it's kinda fine for low traffic APIs.
GP comment reeks of textbook "performance doesn't matter" rhetoric.