> If no one self-writes code anymore anyway, at least use a language that isn't a clusterfuck of bad design decisions

I can get behind the idea that LLM's probably don't need a language designed for humans if humans arent writing it, but the rest of this is just daft. Pythons popularity isn't just pure luck, in fact its only been in recent years that the tooling has caught up to the point where its as easy to setup as it is to write, which should really tell you something if people persevered with it anyway.

I'm sorry your favourite language doesnt have the recognition it so rightfully deserves, but reducing python to just "stupid language for stupid people" is, well, stupid

Python is the blub language now.

Keep in mind that when Graham coined that term Java and C++ were considered blub languages.

Speaking as a grey beard myself, I think its safe to say that the grey beards among us will always deride those who didn't have to work as hard as they did.

And Python is four years older than Java.

Python existed for years before uv with a huge ecosystem, and will continue to do so after/if it dies

uv, yes*, but really PEP 723:

https://peps.python.org/pep-0723/

* disclosure: We are a commercial client of astral.sh

It’ll probably be a game changer for scripts, yes. Writing “portable” Python scripts was a nice exercise, though (and will be, for a while).

This is cool! I ended up also inventing my own syntax to place at the top of one-off scripts to specify deps. (For single-file Python scripts, vs one with a full project dir that has pyproject.toml) I will adopt this instead.

Sounds a lot like vim/emacs modelines. This is neat for standalone scripts.

I agree uv is great but let’s not get carried away here. Poetry is good, pip was fine for many use-cases after they added native lock files.

if you are working on one tiny project on your machine that pips in four packages you probably think pip was OK.

Circa 2017 I was working on systems that were complex enough that pip couldn't build them and after I got to the bottom of it I knew it not my fault but it was the fault of pip.

I built a system which could build usable environments out of pre-built wheels and sketched out the design of a system that was roughly 'uv but written in Python' but saw two problems: (1) a Python dependent system can be destroyed by people messing with Python environments, like my experience is that my poetry gets trashed every six months or so and (2) there was just no awareness by the 'one tiny project on your machine that pips in four packages' people that there was a correctness problem at all and everybody else was blaming themselves for a problem and didn't have a clear understanding of what was wrong with pip or what a correct model for managing python dependencies is (short answer: see maven) or that a 100% correct model was even possible and that we'd have to always settle for a 97% model. The politics looked intractable so I gave up.

Now written in rust, uv evaded the bootstrap problem and it dealt with the adoption problem by targeting 'speed' as people would see the value in that even if they didn't see the value in 'correctness'. My system would have been faster than pip because it would have kept a cache, but uv is faster still.

Well said.

I have used them all and UV is the only one that actually solves the problem.

It’s insane that people would suggest that Python can go back.

> everybody else was blaming themselves for a problem and didn't have a clear understanding of what was wrong with pip or what a correct model for managing python dependencies is (short answer: see maven)

I always looked down on the Java ecosystem but if it turns out Maven had a better story all along and we all overlooked it, that's wild.

Maven has its own bone headed design where it SILENTLY resolves conflicting dependency branches through a “closest to dep tree root wins” rule.

I still believe Rust is a red herring here. Your ‘uv but written in Python’ would probably have the same success as uv does now, if you did focus on speed over correctness. And I’ve yet to hear about pipx or Poetry getting trashed, but if it is a problem, I don’t think it’s impossible to solve in Python vs Rust.

> The politics looked intractable so I gave up.

So yeah, this is your actual problem. (Don’t worry, I’m in the same camp here.)

As much as I'm a Python fan I strongly disagree here that rust is a red herring.

Having a static binary makes distribution way simplier. There are a bunch of ways you could try to achive something like in python but it would be significantly larger.

Performance-wise writing it in python would have heavy startup overhead and wouldn't be able to get close to the same level of performance.

Obviously you could achive the same thing in many other languages, but rust ends up being a really good fit for making a small static binary for this workload of network heavy, IO-bound, async/threading friendly with the occasional bit of CPU heavy work.

>>> ‘uv but written in Python’

you mean pdm?

Poetry and friends are so bad that many people continued just using pip -r requirements.txt despite knowing about this other stuff

Poetry having users isn’t the metric for success. pip having way less users is.

How is uv awesome and Poetry so bad? They do basically the same things except Astral re-invents the wheel but only part way instead of just relying on the existing tools. uv is fast. As far as I can tell, there's hardly any difference in functionality except for it also replacing PyEnv, which I never use anyway.

uv assuming your local Python is busted to hell and back helps a lot with isolation.

Poetry's CLI would often, for me, just fall over and crash. Crashing a lot is not a fundamental problem in the sense you can fix the bugs, but hey I'm not hitting uv crashes.

pipenv was even worse in terms of just hanging during package resolution. Tools that hang are not tools you want in a CI pipeline!

The end result: `uv run` I expect to work. `pipenv` or `poetry` calls I have to assume don't work, have to put retries into CI pipelines and things like that.

uv has a lot of sensible defaults that prevent clueless developers to shoot their own feet. Uv sync, for example, would uninstall packages not in pyproject.toml

i kind of disagree with this. uv run is clunky, i don't want that. i want to keep the activate the venv and do shit model. i hate uv run as a primitive.

I mean you don't need to use that then. `uv` is still writing to `.venv` by default and you can activate it with `direnv` or w/e.

the point about defaults though, the default or defacto workflow is uv run

Maybe, but that's not how I've been holding it.

I think I have trauma from virtual environments...

Performance aside, uv is more standards compliant than Poetry about the pyproject.toml.

But yes, in terms of user interface they are pretty similar. UV performance really does make the difference.

One of them is written in Rust....

I don't know if it's still true, but ~7 years ago when I last looked at it, Poetry didn't have the kind of UX I have in mind (That Astral/UV do). I remember trying to make it work, and it would choose Python 2 for some reason, despite me never having used it, and it having been obsoleted years before. I remember hitting many problems/errors I can't recall the detail of, but bad UX.

>people continued just using pip -r requirements.txt

What exactly is the issue with this?

The requirements file isn't a lockfile: running that command at different times will give you different venvs.

Right, and that's expected.

let's get carried away.

`uv run` a .py with inline script metadata has all the deps installed and your script running in a venv while poetry is still deciding to resolve...

Ahaha, I feel this comment.

I used to do backend development in superior languages, and sometimes do hobby frontend in superior languages, but my work is Python now. And it kind of has to be Python: we do machine learning, and I work with GDAL and PDAL and all these other weird libraries and everything has Python bindings! I search for "coherent point drift" and of course there's a Python library.

The superior languages I mentioned... perhaps they have like a library for JSON encoding and decoding. You need anything else? Great, now you're a library author and maintainer!

relax, soon u be rewriting the essence of all these libs into something new. python has its days numbered also perhaps for many engineering decisions that are now cheap via llms.

The LLMs write bad python as easily as any other language.

To make it good, you need to review and interate.

It is very hard to manually review AI generated code. May be we have to use another LLM to review and assume everything is good.

This hasn't been my experience. I find LLM code about as hard to review as human code, perhaps a little easier.

I think this means reviewing is the main thing with AI, and therefore the language to use should be one where reviewing is easy, for humans.

indeed, from my perspective doing heavy agentic dev for six months, the language all is implemented should be easy. its api - also. like Swift is super easy to read, but the APIs of underlying libs - not so much. Python is reasonably easy to read, but with GIL and everything is a very slow choice. Zig seems a nice apporach to readability, Rust is definitely not so readable.

we may want to invent something akin to concise math notion, but not so much, in between pseudo-code and math.

Ok, what am I missing, I've used python for many many years. What does UV give us over pip + venv + pyenv?

(I'm not doing this to be a dick, I genuinely want to know what the use case is)

Everything “just works” and is fast - and that’s basically it.

You can run a script with a one liner and it will automatically get you the same python and venv and everything as whoever distributed the python code, in milliseconds if the packages are already cached on your local computer.

Very easy to get going without even knowing what a venv or pypi or anything is.

If you are already an expert you get “faster simpler tooling” and if you are a complete beginner it’s “easy peasy lemon squeezy”.

I've used python for roughly 15 years, and 10 of those years I was paid to primarily write and maintain projects written in Python.

Things got bearable with virtualenv/virtualenv wrappers, but it was never what I would call great. Pip was always painful, and slow. I never looked forward to using them - and every time I worked on a new system - the amount of finaggling I had to do to avoid problems, and the amount of time I spent supporting other people who had problems was significant.

The day I first used uv (about is as memorable to me as the the day I first started using python (roughly 2004) - everything changed.

I've used uv pretty much every single day since then and the joy has never left. Every operation is twitch fast. There has never once been any issues. Combined with direnv - I can create projects/venvs on the fly so quickly I don't even bother using it's various affordances to run projects without a venv.

To put it succinctly - uv gives me two things.

One - zero messing around with virtualenvwrappers and friends. For whatever reason, I've never once run into an error like "virtualenvwrapper.sh: There was a problem running the initialization hooks."

Two - fast. It may be the fastest software I've ever used. Everything is instant - so you never experience any type of cognitive distraction when creating a python project and diving into anything - you think it - and it's done. I genuinely look forward to uv pip install - even when it's not already in cache - the parallel download is epically fast - always a joy.

May I ask what OS and filesystem you’re using?

All of them (well - no HPUX in 15+ years, and I've never used uv in Solaris, or AIX) - but the major two client side environments that I use 'uv' in would be WSL2+Ubuntu/ext4 (work) and macOS/APFS at home.

But - neither the speed nor constant issues with pip/virtualenvwrappers are really a function of the OS/File System.

A frequent theme in this thread (probably most clearly described in https://news.ycombinator.com/item?id=47444936) is that relying on your Python Environment to manager your Python Environment - always ends up in pain. Poetry had this issue as well.

One of the key architectural decisions of Astral was to write the Python Environment Management tooling in rust - so that it could never footgun itself.

It also benefited from very enlightened engineering decisions described here: https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

for one, it's one tool, that does the job of all three.

it just works. i'm not sure how else to describe it other than less faffing about. it just does the right thing, every time. there's a tiny learning curve (mostly unlearning bad or redundant habits), but once you know how to wield it, it's a one stop shop.

and as mentioned, it's crazy fast.

It's not horrifically slow.

> making the python ecosystem bearable

You should really qualify that statement, it implies that the Python ecosystem is bearable.

Bearable compared to what it was.

Yes please, lets start with scraping to bin whole internet using javascript and its family.

See the point ?

uv is nice, but not irreplaceable. An open source, maintenance mode fork would work just as fine. And even if all of uv disappeared today, I’d go just back to Poetry. Slower? Sure, a bit.

...and then I’ve read the rest of your comment. Please do go read the HN guidelines.

I guess it's an individual solution to that, but it's a solution that basically worsens the actual problem, as I see it, which is strict/narrow version pinning with frequent updates to latest and minimal effort to track backwards compatibility let alone try to maintain it. It just turns it into nodejs constant wrestling with package.json changes.