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

291–300 of 468 posts

Re: How uv got so fast

#291

Post by firesteelrain »

ChadNauseam wrote: post #196
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…

I don't know the problem space and I'm sure that the language-agnostic algorithmic improvements are massive. But to me, there's just something about rust that promotes fast code. It's easy to avoid copies and pointer-chasing, for example. In python, you never have any idea when you're copying, when you're chasing a pointer, when you're allocating, and so on. (Or maybe you do, but I certainly don't.) You're so far fro…

Uv is great but seems still everyone is cargo culting Rust. We still have Poetry and PDM.

Re: How uv got so fast

#292

Post by jalk »

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.

There is definitely also a manager dick-measuring contest based on headcount, going on in large orgs.

Re: How uv got so fast

#293

Post by firesteelrain »

zahlman wrote: post #143
IgorPartola wrote: post #140

Earlier quoted context omitted.

You would think so, yet here I am sitting with a node_modules full of crud placed there by npm, waiting for the next supply chain attack.

That argument is FUD. The people who created the NPM package manager are not the people who wrote your dependencies. Further, supply chain attacks occur for reasons that are entirely outside NPM's control. Fundamentally they're a matter of trust in the ecosystem — in the very idea of installing the packages in the first place.

Lack of stronger trust controls are part of the larger issue with npm. Pip, Maven and Go are not immune either but they do things structurally better to shift the problem.

Go: Enforces global, append-only integrity via a checksum database and version immutability; once a module version exists, its contents cannot be silently altered without detection, shifting attacks away from artifact substitution toward “publish a malicious new version” or bypass the proxy/sumdb.

Maven: Requires structured namespace ownership and signed artifacts, making identity more explicit at publish time; this raises the bar for casual impersonation but still fundamentally trusts that the key holder and build pipeline were not compromised.

Re: How uv got so fast

#294

Post by woile »

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,…

nah, a lot of people working on `uv` have a massive amount of experience working on the rust ecosystem, including `cargo` the rust package manager. `uv` is even advertised as `cargo` for python. And what is `cargo`? a FLOSS project.

Lots of lessons from other FLOSS package managers helped `cargo` become great, and then this knowledge helped shape `uv`.

Re: How uv got so fast

#295

Post by oblio »

zahlman wrote: post #270
fragmede wrote: post #251

Earlier quoted context omitted.

> has simply not read and understood Contemporary Python Development 101. They haven't. At the end of the day, they just want their program to work. You and I can design a utopian packaging system, but the physics PhD with a hand-me-down windows laptop and access to her university's Linux research cluster don't care about python other than it has a PITA library situation that UV addresses.

If they are not developers, it's the developer's responsibility to fix that. The developers have many options available for this.

Or they can give them a self contained binary that dodges 80% of these support issues because hear me out - and we've known this for 60+ years:

Users do NOT read the manual. Users ignore warnings. Users double click "AnnaKurnikovaNude.exe".

Re: How uv got so fast

#296

Post by Ar-Curunir »

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,…

IIRC correctly uv was started before Astral (the company working on uv)

Re: How uv got so fast

#297

Post by TheDong »

pnt12 wrote: post #279
kibwen wrote: post #203

Earlier quoted context omitted.

> This is interesting in that I wouldn't expect that the typical resolution involves a particularly large quantity of TOML. I don't know the details of Python's resolution algorithm, but for Cargo (which is where epage is coming from) a lockfile (which is encoded in TOML) can be somewhat large-ish, maybe pushing 100 kilobytes (to the point where I'm curious if epage has benchmarked to see if lockfile parsing is notic…

But once you have a lock file there is no resolution needed, is there? It lists all needed libs and their versions. Given how toml is written, I imagine you can read it incrementally - once a lib section is parsed, you can download it in parallel, even if you didn't parse the whole file yet. (not sure how uv does it, just guessing what can be done)

For whatever it's worth, the toml library uv uses doesn't support streaming parsing: https://github.com/toml-rs/toml/issues/326

Re: How uv got so fast

#298

Post by Nextgrid »

another-account wrote: post #194
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,…

Sounds like you’re really down on FOSS and think FOSS projects don’t get stuff done and have no success? You might want to think about that a bit more.

FOSS can sometimes get stuff done but I'd argue it gets stuff done in spite of all the bickering, not because of it. If all the energy spent on arguments or "design by committee" was spent productively FOSS would go much farther (hell maybe we'd finally get that "year of the Linux desktop").

Re: How uv got so fast

#299

Post by Nextgrid »

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.

They believe they do or that they will in the future and act accordingly.

(whether it will pan out or not is another matter, but in the meantime we got a decent open-source package manager out of it)

Re: How uv got so fast

#300

Post by stavros »

pnt12 wrote: post #282
stavros wrote: post #119

Earlier quoted context omitted.

uvx isn't more risky than `pip install`, which is what I used before.

But with pip you only need to be careful on install - with uvx you need to be careful forever. I'm a big fan of uv, but don't like that part of uvx. (makes me wonder if a small wrapper can do this - safe uvx, or suvx for short)

I generally tend to let the shell autocomplete, so I don't type it out every time, but I see your point. If I use a program more than once or twice, I install it.
Post reply on HN