Hacker News new | ask | show | jobs
by throwaway63467 84 days ago
It’s a small tool shop building a tiny part of the Python ecosystem, let’s not overstate their importance. They burned through their VC money and needed an exit and CLI tool chains are hyped now for LLMs, but this mostly sounds like an acquihire to me. Dev tools are among the hardest things to monetize with very few real winners, so good for them to get a good exit.
12 comments

Small tool shop, burning VC money, true. "Tiny part of the Python ecosystem" is an understatement given how much impact uv has made alone.
Just a tiny project with over 100 million downloads every month, over 4 million every day. No big deal. Just a small shop, don't overstate its importance.

https://pypistats.org/packages/uv

Sure, but if tomorrow uv and ruff ceased to exist, we could all go back to any number of other solutions.
Ruff is nice, but not important, uv is one of the few things making the python ecosystem bearable. Python is a language for monkeys, and if you don't give monkeys good tools, they will forever entangle themselves and you. It is all garbage wrapped in garbage. At least let me deploy it without having to manually detangle all that garbage by version.

I'm done pretending this is a "right tools for the right job" kind of thing, there's wrong people in the right job, and they only know python. If no one self-writes code anymore anyway, at least use a language that isn't a clusterfuck of bad design decisions, and has 1 trillion lines of code in the collective memory of people who don't know what a stack is.

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

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.

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.

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

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

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.

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

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.

Maybe you could. I would stare longingly into the void, wondering if I can ever work another python project after having experienced uv, ruff, and ty.

Such an outcome would make me wonder regarding the wisdom of "It is better to have love and lost than to have never loved at all."

I was using poetry pretty happily before uv came along. I’d probably go back.

Note that uv is fast because — yes, Rust, but also because it doesn’t have to handle a lot of legacy that pip does[1], and some smart language independent design choices.

If uv became unavailable, it’d suck but the world would move on.

[1] https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

Maybe I could give up uv, but giving up ruff would suck.
It is an MIT licensed project, someone will absolutely fork it.
You seem to be underestestimating the laziness of the people, and overestimating their resolve. Angry forks usually don't last, angst doesn't prevent maintenance burnouts.
Ruff is performant but finds about half the issues Pylint does (see https://github.com/astral-sh/ruff/issues/970). Ty is quantitatively the worst of the well-known type checkers (see https://news.ycombinator.com/item?id=47398023). Uv is Astral's only winner.
You are aware that ty has only recently entered beta status?

Ruff isn’t stable yet either and has evolved into the de facto standard for new projects. It has more than double the amount of rules than Pylint does. Also downloaded more than 3 times as often as Pylint in the past month.

Pylint has some advantages, sure, but Ruffs adoption speaks for itself. Pylint is 25 years old. You’d hope they do some things better.

Saying that uv is their only winner is a hilarious take.

Maybe consider something other than python.
Always choose the best tool for the job.

Then import that tool and and check if __name__ == "__main__"

Good luck with that. I haven't been successful at convincing anyone to move away from it. I'm so fucking sick of writing Python at work lol
While I hope it never comes to that, all the code is MIT licensed, I would assume everyone would make the sensible decision for fork it.
I see Apache and MIT license files in their GitHub. What's to prevent the community from forking and continuing development if the licenses change?
The same things that prevented "community" from building the tool in the first place
i think the main problem was that people didn't believe that pip was broken, or didn't think there was any value in a 100% correct package manager over a 97% correct package manager (e.g. misread "worse is better")

I had the problem basically understood in 2018 and I am still pissed that everybody wanted to keep taking their chances with pip just like they like to gamble with agent coders today.

Now that people know a decent package manager is possible in Python I think there is going to be no problem getting people to maintain one.

that makes zero sense to me. developing something like ruff from scratch takes a lot of things happening - someone having the idea, the time to develop it from scratch in their free time, or the money to do it as a job, and perhaps the need to find collaborators if it's too large a project for one person. but now ruff is there, there's no need to build it from scratch. if I wanted to build a python linter or formatter I would simply fork ruff and build on top of it. as others have said in this subthread, that's the whole point of open source!
Cannot we at one point consider the tool to be "done"? I mean, what is there to constantly change and improve? Genuinely curious. It sounds like a tool that can be finished. Can it not be?
Personally I would stop using Python again. uv is the one thing that made it bearable.
Eurgh, I do not want to ever touch Poetry or pyenv again, thank you very much.
I would just ditch Python, like I did 8 years ago.
…if tomorrow python ceased to exist, we could all go back to any number of other solutions.
I dont wanna go back to micromamba, pixi is my happy place (which builds on uv).
>Sure, but if tomorrow uv and ruff ceased to exist, we could all go back to any number of other solutions.

Or, more relevant to this conversion: If they closed source tomorrow, the community could fork the current version.

UV is so much nicer than the other options.
I wish that were also true for the case of Claude/Codex/etc
I mean, if you believe the hype on this website, Claude Code could build a perfect clone of uv in a few hours using only the documentation.
I do feel like it is overstated, and the number of downloads is not a good metric at all. There are npm packages with many millions of downloads, too.
You can take my padleft function from my cold dead hands, but it will live forever in example code!
That says more about the sad state of modern CI pipelines than anything about uv's popularity.

Not disputing that it's a great and widely used tool, BTW.

The “requests” package gets downloaded one billion times every month, should that be a multi billion dollar VC company as well? It’s a package manager and other neat tooling, it’s great but it’s hardly the essence of what makes Python awesome, it’s one of the many things that makes this ecosystem flourish. If OpenAI would enshittify it people would just fork or move on, that’s all I’m saying, it’s not in any way a single point of failure for the Python ecosystem.
> the essence of what makes Python awesome

This is not the point of uv or any good package manager. The point is what prevents Python to suck. For a long time package management had been horrible in Python compared what you could see in other languages.

Don't understate its importance. I've been using Python for more than 30 years. They solved a problem that a lot of smart people didn't solve (). Python developer experience improved an order of magnitude.

() Sure, they were on the shoulders of giants

Not including direct downloads via the native installers, Homebrew, Winget, or Docker, mind you.
I mean, these sorts of numbers speak to the mind-bogglingly inefficient CI workflows we as an industry have built. I’d be surprised if there were 4 million people in the world who actually know what ‘uv’ is.
It's not difficult to download something yourself 4 million times every day to look popular :)
They have some nice ideas. But if they turn to shit you can just fork their tools and use that instead.
Agreed.

Maybe there needs to be some nonprofit watchdog which helps identify those cases in their early stages and helps bootstrap open forks. I'd fund to a sort of open capture protection savings account if I believed it would help ensure continuity of support from the things I rely on.

Right. If anything, this "tiny part" has pretty much taken over Python and turned it from OSS BDFL language into a company-backed one (like Erlang, Scala, C#).
I am still not sure why everyone jumped on uv. Sure, it's quicker than pip, but an installation rarely takes so long as to become annoying. Anyway, pip is still there, so whatever impact they have made can be rolled back if they try to pull the rug
I'm not sure but it seems to be because of dependency management behaviors I find confusing. Like, I found out that apparently people or packages would just do this `pip freeze > requirements.txt` or otherwise just not pay attention to what version limitations there are. It's not something that I ever really ran into much though
Do you have any statistics for that?
uv has almost 2x the number of monthly downloads Poetry has.

- https://pypistats.org/packages/poetry - https://pypistats.org/packages/uv

In the 2024 Python developer survey, 18% of the ecosystem used Poetry. When I opened this manifold question[0], I'm pretty sure uv was about half of Poetry downloads.

Estimating from these numbers, probably about 30% of the ecosystem is using `uv` now. We'll get better numbers when the 2025 Python developer survey is published.

Also see this: https://biggo.com/news/202510140723_uv-overtakes-pip-in-ci-u...

[0]: https://manifold.markets/JeremiahEngland/will-uv-surpass-poe...

anecdotally every place ive worked at has switched over and never looked back.
Same. It's game-changing - leaps and bounds above every previous attempt to make Python's packaging, dependency management, and dev workflow easy. I don't know anyone who has tried uv and not immediately thrown every other tool out the window.
I use uv here and there but have a bunch of projects using regular pip with pip-tools to do a requirements.in -> requirements.txt as a lockfile workflow that I've never seen enough value in converting over. uv is clearly much faster but that's a pretty minor consideration unless I were for some reason changing project dependencies all day long.

Perhaps it never grabbed me as much because I've been running basically everything in Docker for years now, which takes care of Python versioning issues and caches the dependency install steps, so they only take a long time if they've changed. I also like containers for all of the other project setup and environment scaffolding stuff they roll up, e.g. having a consistently working GDAL environment available instantly for a project I haven't worked on in a long time.

2 things: First, you can (and should) replace your `pip install` with `uv pip install` for instant speed boost. This matters even for Docker builds.

Second, you can use uv to build and install to a separate venv in a Docker container and then, thanks to the wonders of multistage Docker builds, copy that venv to a new container and have a fully working minimal image in no time, with almost no effort.

been in the python game a long time and i've seen so many tools in this space come and go over the years. i still rely on good ol pip and have had no issues. that said, we utilize mypy and ruff, and have moved to pyproject etc to remotely keep up with the times.
uv solved it, it will be the only tool people use in 2 more years. if you’re a python shop / expert then you can do pip etc but uv turned incidental python + deps from a huge PITA for the rest of us, to It Just Works simplicity on the same level or better than Golang.
Then can they please figure out some way of invoking it that doesnt require prefixing everything with 'uv'
I don't want software on my computer, that just downloads and installs random stuff. This is the job of the OS in particular the package manager.
Geospatial tends to be the Achilles heel for python projects for me. Fiona is a wiley beast of a package, and GDAL too. Conda helped some but was always so slow. Pip almost uniformly fails in this area for me.
Yup, the fact UV just installed geopandas out of the box with no issues blew my mind.
VC money bailing out other VCs. A tale as old as time.
As a point of information: Astral did not, in fact, burn through its VC money. I agree that dev tools are difficult to monetize, though.

(Source: I'm an Astral employee.)

> As a point of order: Astral did not, in fact, burn through its VC money.

That's a point of information, not a point of order.

Is pointing out the incorrect use of a point of order itself a point of order, or also a point of information?
You're right, I've edited it.
what does that mean
There's a thing called "Robert's Rules of Order" that lays out a framework for how a group of people with different views can make decisions in an orderly way. It's very widely used in the US - wikipedia says "church groups, county commissions, homeowners' associations, nonprofit associations, professional societies, school boards, trade unions, and college fraternities and sororities".

If you've ever heard a line like "Mr Chair, I make a motion to X the Y" and then someone pipes up from a different part of the room "I second the motion!" and then someone important-looking says "A motion has been made and seconded, you may have the floor" - They're doing Robert's Rules.

And that's most of what I knew about Robert's Rules a minute ago, until I looked up the distinction GP was making above:

Point of Order: When a member thinks that the rules of the assembly are being violated, s/he can make a Point of Order (or "raise a question of order," as it is sometimes expressed), thereby calling upon the chair for a ruling and an enforcement of the regular rules.

Point of Information: a request for information on a specific question, either about process or about the content of a motion. A point of information does not give the speaker the privilege to provide information. If you have information for the body, raise your hand to be put on the speakers list.

from https://www.sheridan.edu/app/uploads/2018/11/Roberts-Rules-M...

That's right. You can also introduce or correct information with a point-of-information, at least as I was taught them.

Other types of interjection are point of personal privilege (eg seat is uncomfortable) and point of inquiry (clarification).

I came across them in the debating world. Point of information can be pretty effective if you're able to make a statement of fact contradicting something the other side declared.

See also: https://senate.oregonstate.edu/sites/senate.oregonstate.edu/...

Finally someone competent to answer the crucial question. Taken into account the enormous amount of excellent work you did, and the fact that dev tools are hard to monetize, what was your strategy?
You can find some resources on our strategy in previous blog posts, like this one on pyx[1].

[1]: https://astral.sh/blog/introducing-pyx

Are you going to join codex team as well? I am curious about how the codex code base will evolve after you guys joined. It is going to affect Python/Rust toolchains tremendously.
Check this HN thread from 8 months ago: https://news.ycombinator.com/item?id=44358216
UV is arguably this decade's most important addition to the python ecosystem. They are a small, but they are important.
uv is the best thing to happen to package management in Python.

It's not perfect, but it is light-years better than what preceded it.

I jumped ship to it and have not looked back. (So have many of my clients).

Uv is the defacto way to do projects. Ty is really really good. Ruff is the defacto linter. I mean they’ve earned a lot of clout.
> Dev tools are among the hardest things to monetize with very few real winners, so good for them to get a good exit.

I'm on the fence about cancelling my JetBrains subscription I've had for nearly 10 years now. I just don't use it much. Zed and Claude Code cover all my needs, the only thing I need is a serious DataGrip alternative, but I might just sit down with Claude and build one for myself.

I'm curious what you think of https://seaquel.app as a DataGrip alternative.

It's a project I'm working on to build a database management product I've always wanted.

I spend way too much time obsessing over UX but hope people appreciate it :).

What do you want in your datagrip alternative. I'm working on some stuff, and interested to hear how people approach data with LLMs
I've been using DBeaver CE since I lost my DataGrip license.
That's kind of like saying Cargo is a small part of the Rust ecosystem.

It's not there yet, but it's getting there.

That was my feeling - more than 'owning' uv etc I could see this as being about getting people onboard who had a proven track record delivering developer tooling that was loved enough to get wide adoption
They were hyped here without any pushback. Maybe OpenAI thinks the Astral folks will now evangelize and foist Codex and ChatGPT onto the open source "community".

People need to be very careful about resisting. OpenAI wants to make everyone unemployed, works with the Pentagon, steals IP, and copyright whistleblowers end up getting killed under mysterious circumstances.

Every uv-related post here had a few people going "i don't want to use VC funded stuff!! what about rug pull!!", although perhaps they were drowned out eventually all the people (like me) going "uv is fantastic and solves 15 years of python packaging hell"
Maybe it is a GenX, Boomer thingie, but setting a couple of environment variables, or multiple virtual envs hardly felt as packaging hell.
Perhaps you and I are POSIXly Correct people who easily stay on the golden path, but for the average Python user the hell is all too common: https://xkcd.com/1987/
given that they delivered the goods I would not say they were "hyped"
> They were hyped here without any pushback.

This is untrue. People frequently complained that they were VC funded and used it to justify mistrust.

Take this discussion, for example. Completely dominated by the topic.

https://news.ycombinator.com/item?id=44892209

> tiny part of the Python ecosystem

https://xkcd.com/2347/

uv and ruff is not tiny part anymore, its growing fast
Not to mention their language server + type checker `ty` is incredible. We moved our extremely large python codebase over from MyPy and it's an absolute game changer.

It's so fast in fact that we just added `ty check` to our pre-commit hooks where MyPy previously had runtimes of 150+ seconds _and_ a mess of bugs around their caching.

This is so dystopian… they built something that worked and now are being “acquihired” into oblivion, and we’re supposed to be happy about it? I’m glad a few of the early people just got rich I guess, but it seems like a terrible system overall.