Interesting point of view and I think feedback is good. Although I agree with the overall sentiment of the article, I disagree with the intensity of the criticism.

Having a command runner within your project will mask a lot of the issues the author mentioned. And although, in my experience, having a command runner for mid-sized projects and up is useful for many things, masking the UX issues means there's a problem.

I got on the uv bandwagon relatively recently as most of my work is maintaining older python projects so I've been using it for new builds. Although the speed part is welcome, I couldn't see what the big deal is and mostly keep on using it because it is a popular tool(there are benefits to that in my line of work) and not necessarily because it can do something that couldn't be done before though with a couple of other tools. Whether it is beneficial or detrimental to having all of that functionality within one tool, to me, is a matter of opinion.

The problem to me is that I've seen this cycle many times before. New tool shows up claiming it is far superior to everything else with speed being a major factor and everyone else is doing it wrong. Even though the new tool does a fraction of what the old "bad" tool is doing. With adoption comes increased functionality and demands and the new tool starts morphing into the old tool with the same claimed downsides. The UX issues to me are a symptom of that process.

I still think uv is a fine tool. I've used poetry before and sometimes plain old pip. They're all fine with each tool catering to different use cases, in my opinion. Sometimes you have to add pyenv, sometimes you don't. Sometimes you add direnv, sometimes you don't and so on. And I've cursed at everyone of them at times. However, the fanboyism is very strong with uv which makes me wonder why.

▲

skeledrew 4 minutes ago | parent | next [-]

For me, and I suspect many others, the big deal is that it makes env management simply disappear. Before uv I used conda+poetry for years, and there was always the need to activate the env before doing anything (I used autoenv and ended up with .env files containing "conda activate <env_name>" in every project), and various other small pains that I actually became accustomed to over the years, but then I'd always be surprised when someone said X didn't work when it was fine for me. The uv came and I felt a great relief that I didn't know I was missing, and suddenly there were also no more surprises.

▲

daemonologist 2 hours ago | parent | prev [-]

uv has a lot of great features, but the dependency resolution is why I'm a fanboy. It can resolve trees that pip gives up on, and it does it 20x faster than poetry (100x faster than pip) - saves me half an hour on some big projects. All the python resolution and environment management and stuff is just gravy.

▲

scorpioxy an hour ago | parent | next [-]

I've only seen pip give up twice and both times were due to bugs that were actively being worked on and the project dependencies were quite old. Perhaps that's why I am less impressed. Don't get me wrong, working faster without any downside is great. But I don't change dependencies all that often for it to matter if it does it in 5 seconds or 30.

▲

jim33442 an hour ago | parent | prev [-]

Yeah, this is when it really matters that they wrote it in a CPU-performant language. There have been times I pointed uv at a random pip-managed GitHub project to rescue it because the author forgot to specify some versions and entire deps in requirements.txt. It even took uv a bit of chugging to find an overlap. Also wow, those packages had a lot of pointless breaking changes.

▲

saghm an hour ago | parent | next [-]

I don't do Python all that often, but I got sold on uv when a year or so ago I wanted to try to fix a small bug in a relatively niche Python open source I was trying to use, and it used a packaging tool I hadn't even heard of before (pdm). I was able to run `uv tool run pdm <whatever other arguments I needed>` without having to know anything about how pdm worked or worry about how to properly install yet another python tool and figure out whether I needed to be concerned about whether it might try to use system (or user local) versions of packages I had installed or get pointed at a magic hidden directory that I had to create first. When I realized I might never have to care about that ever again for any Python tool, I was hooked.

	▲	jim33442 30 minutes ago \| parent [-]
		Even Poetry wants you to install it via pipx, which is itself managed by pip. I'm not going to do that.

▲

foobarbecue an hour ago | parent | prev [-]

Rust isn't the main reason it's fast. The main reason is willingness to break backwards compatibility. https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

	▲	jim33442 40 minutes ago \| parent \| next [-]
		Even with that, uv took some time at 100% CPU during dep resolution, which I imagine would've been much slower if in pure Python instead. Unless pip's backtracking is already in C.
	▲	saghm 36 minutes ago \| parent \| prev [-]
		I don't find that to be a particularly strong argument that a Python package manager would be possible to be in the same ballpark of performance as a Rust one. There's quite a lot of it that either doesn't support the idea of Python being capable of the same level of performance or actively supports the opposite. > PEP 658 went live on PyPI in May 2023. uv launched in February 2024. uv could be fast because the ecosystem finally had the infrastructure to support it. A tool like uv couldn’t have shipped in 2020. The standards weren’t there yet. > Other ecosystems figured this out earlier. Cargo has had static metadata from the start. npm’s package.json is declarative. Python’s packaging standards finally bring it to parity. Are there any tools written in Python since then that are anywhere as close to as fast as uv when operating on packages that use this newer format? I've yet to hear of one. > No .egg support. Eggs were the pre-wheel binary format. pip still handles them; uv doesn’t even try. The format has been obsolete for over a decade. It seems dubious that adding support for egg would prevent uv from being as fast on packages that don't use that format. > Virtual environments required. pip lets you install into system Python by default. uv inverts this, refusing to touch system Python without explicit flags. This removes a whole category of permission checks and safety code. Passing `--user` to `pip install` doesn't seem to make things noticeably faster in most cases. > Parallel downloads. pip downloads packages one at a time. uv downloads many at once. Any language can do this. Any language with a global interpreter lock certainly can't do that as effectively as a language without one. > Python-free resolution. pip needs Python running to do anything, and invokes build backends as subprocesses to get metadata from legacy packages. uv parses TOML and wheel metadata natively, only spawning Python when it hits a setup.py-only package that has no other option. This one is pretty self-explanatory. The section at the end somewhat overlaps with the parts I called out, and I recognize that the author of that post is almost certainly more familiar with the specifics of uv and Python package management than me, but with a lack of concrete example of a Python package manager that's anywhere close to the level of performance of a Rust one, I can't help but feel like pip would probably be quite noticeably slower than a Rust alternative written with an identical feature set (whether that feature set is "what pip currently supports" or "the minimal set of features described here"). I could imagine it being something like, pip could maybe be optimized from being 50x slower than uv to only 5x, but if that's the case, I think "Rust isn't the main reason it's fast" is a bit of an oversimplification when the discussion is about comparisons to alternatives that are all written in Python.