Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How uv got so fast

nesbitt.io

Post reply on HN
Print view View original

321–330 of 468 posts

Re: How uv got so fast

#321

Post by swores »

raincole wrote: post #284
Nextgrid wrote: post #158

Earlier quoted context omitted.

It's not just greenfield-ness but the fact it's a commercial endeavor (even if the code is open-source). Building a commercial product means you pay money (or something they equally value) to people to do your bidding. You don't have to worry about politics, licensing, and all the usual FOSS-related drama. You pay them to set their opinions aside and build what you want, not what they want (and if that doesn't work,…

Is there any sign telling Astral is actually making money via uv? How sustainable is it? I suggest everyone save this comment and review it five years later.

Keep in mind that "making money" doesn't have to be from people paying to use uv.

It could be that they calculate the existence of uv saves their team more time (and therefore expense) in their other work than it used to create. It could be that recognition for making the tool is worth the cost as a marketing expense. It could be that other companies donate money to them either ahead of time in order to get uv made, or after it was made to encourage more useful tools to be made. etc

Edit: 6 months ago, user simonw wrote a HN comment "Here's a loose answer to that question from uv founder Charlie Marsh last September [2024] : https://hachyderm.io/@charliermarsh/113103564055291456

«« I don't want to charge people money to use our tools, and I don't want to create an incentive structure whereby our open source offerings are competing with any commercial offerings (which is what you see with a lost of hosted-open-source-SaaS business models).

What I want to do is build software that vertically integrates with our open source tools, and sell that software to companies that are already using Ruff, uv, etc. Alternatives to things that companies already pay for today.

An example of what this might look like (we may not do this, but it's helpful to have a concrete example of the strategy) would be something like an enterprise-focused private package registry. A lot of big companies use uv. We spend time talking to them. They all spend money on private package registries, and have issues with them. We could build a private registry that integrates well with uv, and sell it to those companies. [...]

But the core of what I want to do is this: build great tools, hopefully people like them, hopefully they grow, hopefully companies adopt them; then sell software to those companies that represents the natural next thing they need when building with Python. Hopefully we can build something better than the alternatives by playing well with our OSS, and hopefully we are the natural choice if they're already using our OSS. »»

Re: How uv got so fast

#322

Post by tonyhart7 »

raincole wrote: post #284
Nextgrid wrote: post #158

Earlier quoted context omitted.

It's not just greenfield-ness but the fact it's a commercial endeavor (even if the code is open-source). Building a commercial product means you pay money (or something they equally value) to people to do your bidding. You don't have to worry about politics, licensing, and all the usual FOSS-related drama. You pay them to set their opinions aside and build what you want, not what they want (and if that doesn't work,…

Is there any sign telling Astral is actually making money via uv? How sustainable is it? I suggest everyone save this comment and review it five years later.

"Is there any sign telling Astral is actually making money via uv? How sustainable is it?"

maybe they would get acquihire like Bun ???? idk, somebody defo needs this

Re: How uv got so fast

#323

Post by ngc248 »

Nextgrid wrote: post #187
xvector wrote: post #181

Earlier quoted context omitted.

Hard disagree, most of my coworkers make well north of $1M and office politics is at an all time high. I believe office politics happens when there are simply too many people at a company or org.

I think too many people happens because a company would rather hire 10 "market rate" people than 3 well-compensated ones. Headcount inflation dilutes responsibility and rewards, so even if one of the "market rate" guys does the best work possible they won't get rewarded proportionally... so if hard work isn't going to get them adequate comp, maybe politics will.

Parkinson's law of organizations clearly explains why orgs grow https://en.wikipedia.org/wiki/Parkinson%27s_law

Re: How uv got so fast

#324

Post by twelvedogs »

Nextgrid wrote: post #158
orliesaurus wrote: post #148

The most surprising part of uv's success to me isn't Rust at all, it's how much speed we "unlocked" just by finally treating Python packaging as a well-specified systems problem instead of a pile of historical accidents. If uv had been written in Go or even highly optimized CPython, but with the same design decisions (PEP 517/518/621/658 focus, HTTP range tricks, aggressive wheel-first strategy, ignoring obviously de…

It's not just greenfield-ness but the fact it's a commercial endeavor (even if the code is open-source). Building a commercial product means you pay money (or something they equally value) to people to do your bidding. You don't have to worry about politics, licensing, and all the usual FOSS-related drama. You pay them to set their opinions aside and build what you want, not what they want (and if that doesn't work,…

it wouldn't work in a foss world because there's like 5 guys doing that shit it in their spare time. that said... github...

Re: How uv got so fast

#325

Post by andai »

orliesaurus wrote: post #148

The most surprising part of uv's success to me isn't Rust at all, it's how much speed we "unlocked" just by finally treating Python packaging as a well-specified systems problem instead of a pile of historical accidents. If uv had been written in Go or even highly optimized CPython, but with the same design decisions (PEP 517/518/621/658 focus, HTTP range tricks, aggressive wheel-first strategy, ignoring obviously de…

It just has to do with values. If you value perf you aren't going to write it in Python. And if you value perf then everything else becomes a no brainer as well.

It's the same way in JS land. You can make a game in a few kilobytes, but most web pages are still many megabytes for what should have been no JS at all.

Re: How uv got so fast

#326

Post by NewsaHackO »

DrawTR wrote: post #182
pecheny wrote: post #25

The content is nice and insightful! But God I wish people stopped using LLMs to 'improve' their prose... Ironically, some day we might employ LLMs to re-humanize texts that had been already massacred.

Editing the post to switch five "it's X not Y"s[1] is pretty disappointing. I wish people were more clear with their disclosure of LLM editing. [1]: https://github.com/andrew/nesbitt.io/commit/0664881a524feac4...

I recsind my previous statement. Also, people have to stop putting everything on github.

Re: How uv got so fast

#327

Post by klibertp »

oefrha wrote: post #304
zahlman wrote: post #268

Earlier quoted context omitted.

> Linux systems commonly already provide an outdated system Python you don’t want to use Even with LTS Ubuntu updated only at EOL, Python will not be EOL most of the time. > A single Python version for the entire system fundamentally doesn’t work for many people thanks to shitty compat story in the vast ecosystem. My experience has been radically different. Everyone is trying their hardest to provide wheels for a wid…

For much of the ML/scientific ecosystem, you're lucky to get all your deps working with the latest minor version of Python six months to a year after its release. Random ML projects with hundreds to thousands of stars on GitHub may only work with a specific, rather ancient version of Python. > Because otherwise this problem is trivially solved by anyone competent. In particular, building and installing Python from so…

> Why not?

Time. CPython compiles in a few minutes on an underpowered laptop. I don't recall last time I compiled GCC, but I had to compile LLVM and Clang recently, and it took significantly longer than "a few minutes" on a high-end desktop.

Re: How uv got so fast

#328

Post by akoboldfrying »

Pawamoy wrote: post #273
Revisional_Sin wrote: post #271

> Ignoring requires-python upper bounds. When a package says it requires python Erm, isn't this a bit bad?

No. When such upper bounds are respected, they contaminate other packages, because you have to add them yourself to be compatible with your dependencies. Then your dependents must add them too, etc. This brings only pain. Python 4 is not even a thing, core developers say there won't ever be a Python 4.h

> you have to add them yourself to be compatible with your dependencies

This is no more true for version upper bounds than it is for version lower bounds, assuming that package installers ensure all package version constraints are satisfied.

I presume you think version lower bounds should still be honoured?

Re: How uv got so fast

#329

Post by yakshaving_jgt »

rao-v wrote: post #217

I have to say it's just lovely seeing such a nicely crafted and written technical essay. It's so obvious that this is crafted by hand, and reading it just reemphasises how much we've lost because technical bloggers are too ready to hand the keys over to LLMs.

This post was very clearly written with an LLM.

Re: How uv got so fast

#330

Post by jacquesm »

zahlman wrote: post #265
112233 wrote: post #257

Earlier quoted context omitted.

Not many normal people want to install python. Instead, author of the software they are trying to use wants them to install python. So they follow readme, download windows installer as you say, pip this pipx, pipx that conda, conda this requirements.txt, and five minutes later they have magic error telling that tensorflow version they are installing is not compatible with pytorch version they are installing or some s…

Scenarios like that are simply not realistic. Besides which, multiple solutions exist for bundling Python with an application.

Scenarios like that occur daily. I do quite a bit of software development and whenever I come across something that really needs python I mentally prepare for a day of battle with the various (all subtly broken) package managers, dependency hell and circular nonsense to the point that I am also ready to give up on it after a day of trying.

Just recently: a build of a piece of software that itself wasn't written in python but that urgently needed a very particular version of it with a whole bunch of dependencies that refused to play nice with Anaconda for some reason (which in spite of the fact that it too is becoming less reliable is probably still the better one). The solution? Temporarily move andaconda to a backup directory, remove the venv activation code from .bashrc and compile the project, then restore everything to the way it was before (which I need it to be because I have some other stuff on the stove that is built using python because there isn't anything else).

And let's not go into bluetooth device support in python, anything involving networking that is a little bit off the beaten path and so on.

Post reply on HN