Live data from Hacker News

Uv is the best thing to happen to the Python ecosystem in a decade

emily.space

621–630 of 1001 posts

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#621

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

> but lock files and consistent installs are amazing

Yes, though poetry has lock files, and it didn't create the same positive feelings uv does :)

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#623

Uv is so good. I'm a curmudgeon about adopting new tooling, and tried uv with a lot of skepticism, but it was just better in every way. And even if it wasn't so polished and reliable, the raw speed makes it hard to go back to any other tool. Uv combined with type hints reaching critical mass in the Python ecosystem, and how solid PyLance is in VSCode, feels so good it has made me consider investing in Python as my pr…

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

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#624

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

other than being much slower than uv, conda has worked great for years

I do prefer uv but it's not like sane python env management hasn't existed

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#625

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

conda was great to me

same here; I now prefer uv but conda served us very well, and allowed us to maintain stable reproducible environments; being able to have multiple environments for a given project is also sometimes handy vs a single pyproject.toml

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#626

Uv is so good. I'm a curmudgeon about adopting new tooling, and tried uv with a lot of skepticism, but it was just better in every way. And even if it wasn't so polished and reliable, the raw speed makes it hard to go back to any other tool. Uv combined with type hints reaching critical mass in the Python ecosystem, and how solid PyLance is in VSCode, feels so good it has made me consider investing in Python as my pr…

Am I the only one that's sad that poetry happened before pdm otherwise we might have had pdm as a standard instead of uv, addressing many of the things uv addresses without all the extra bells and whistles that make it cumbersome. I don't like the wedding between package manager and install manager.

... but then again neither pdm nor uv would have happened without poetry.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#627

It’s puzzling why Python became the de facto standard scripting language rather than Ruby when the tooling was so inferior.

the ecosystem, especially math / stats / data analysis packages. Also Google used python, making it more popular

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#629
post #42

For single-file Python scripts, which 99% of mine seem to be, you can simplify your life immensely by just putting this at the top of the script: #!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.11" # dependencies = [ "modules", "here" ] # /// The script now works like a standalone executable, and uv will magically install and use the specified modules.

If I were to put on my security hat, things like this give me shivers. It's one thing if you control the script and specified the dependencies. For any other use-case, you're trusting the script author to not install python dependencies that could be hiding all manner of defects or malicious intent. This isn't a knock against UV, but more a criticism of dynamic dependency resolution. I'd feel much better about this i…

I didn't see it in the comments, but FWIW you can choose specific dependencies. You can use regular [dependency specifiers](https://packaging.python.org/en/latest/specifications/depend...), see [PEP 723](https://packaging.python.org/en/latest/specifications/inline...).

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#630
post #42

Earlier quoted context omitted.

If I were to put on my security hat, things like this give me shivers. It's one thing if you control the script and specified the dependencies. For any other use-case, you're trusting the script author to not install python dependencies that could be hiding all manner of defects or malicious intent. This isn't a knock against UV, but more a criticism of dynamic dependency resolution. I'd feel much better about this i…

You’re about to run an untrusted python script. The script can do whatever it wants to your system. Dependencies are the least of your worries.

The script is just a cat or vim away from audit. Its dependencies on the other hand…
Post reply on HN