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

261–270 of 468 posts

Re: How uv got so fast

#261

Post by dpark »

goalieca wrote: post #235
dpark wrote: post #183

Earlier quoted context omitted.

Politicking is just group dynamics. In large companies people engage in politics because it becomes necessary to accomplish large things. Of course a group can also have bad actors but that’s not really an issue with politics specifically. Politics are neither good nor bad.

> In large companies people engage in politics because it becomes necessary to accomplish large things. At a large company, your job after a certain level depends on your “impact” and “value delivered”. The challenge is getting 20 other teams to work on your priorities and not their priorities. They too need to play to win to keep their job or get that promotion.

For software engineering, “impact” or “value delivered” are pretty much always your job unless you work somewhere really dysfunctional that’s measuring lines of code or some other nonsense. But that does become a lot about politics after some level.

I would not say it’s about getting other people aligned with your priorities instead of theirs but rather finding ways such that your priorities are aligned. There’s always the “your boss says it needs to help me” sort of priority alignment but much better is to find shared priorities. e.g. “We both need X; let’s work together.” “You need Foo which you could more easily achieve by investing your efforts into my platform Bar.”

Re: How uv got so fast

#262

Post by zahlman »

eviks wrote: post #224
zahlman wrote: post #222

Earlier quoted context omitted.

> Unless memory mapped by the OS with no impact on runtime for unused parts? Yeah, this is presumably why a no-op `uv` invocation on my system takes ~50 ms the first time and ~10 ms each other time. > Exactly, so again have no impact? Only if your invocation of pip manages to avoid an Internet request. Note: pip will make an Internet request if you try to install a package by symbolic name even if it already has the…

> Only if your invocation of pip manages to avoid an Internet request. Yes it does, by definition, the topic of discussion is the impact of unused code paths? How is http cache relevant here? That's a used path!

I got confused by the direction of the discussion.

My original point was that Requests imports in pip used to not be deferred like that, so you would pay for them up front, even if they turned out to be irrelevant. (But also they are relevant more often than they should be, i.e. the deferral system doesn't work as well as it should.)

Part of the reason you pay for them is to run top-level code (to create function and class objects) that are irrelevant to what the program is actually doing. But another big part is the cost of actually locating the files, reading them, and deserializing bytecode from them. This happens at import time even if you don't invoke any of the functionality.

Re: How uv got so fast

#263

Post by zahlman »

BiteCode_dev wrote: post #134

Other design decisions that made uv fast: - uncompressing packages while they are still being downloaded, in memory, so that you only have to write to disk once - design of its own locking format for speed But yes, rust is actually making it faster because: - real threads, no need for multi-processing - no python VM startup overhead - the dep resolution algo is exactly the type of workload that is faster in a compile…

> uncompressing packages while they are still being downloaded

... but the archive directory is at the end of the file?

> no python VM startup overhead

This is about 20 milliseconds on my 11-year-old hardware.

Re: How uv got so fast

#264

Post by zahlman »

dmarwicke wrote: post #212

wait, zero-copy deserialization isn't rust-specific. you can mmap structs in C. done it before, works fine

The point is that it would be difficult in Python, compared to in "system" compiled languages generally.

Re: How uv got so fast

#265

Post by zahlman »

112233 wrote: post #257
zahlman wrote: post #239

Earlier quoted context omitted.

If I want to install Python on Windows and start using pip, I grab an installer from python.org and follow a wizard. On Linux, I almost certainly already have it anyway. If I want to bootstrap from uv on Windows, the simplest option offered involves Powershell. Either way, I can write quite a bit with just the standard library before I have to understand what uv really is (or what pip is). At that point, yes, the pip…

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.

Re: How uv got so fast

#266

Post by oarsinsync »

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.

Alternatively, companies hire multiple subject domain experts, and pay them handsomely.

The experts believe they've been hired for the value of their opinions, rather than for being 'yes-people', and have differing opinions to each other.

At a certain pay threshold, there are multiple peoples who's motivation is not "how do I maximise my compensation?" and instead is "how do I do the best work I can?" Sometimes this presents as vocal disagreements between experts.

Re: How uv got so fast

#267

Post by yunohn »

rick_dalton wrote: post #114
yunohn wrote: post #44

Earlier quoted context omitted.

“Why this matters” being the final section is a guaranteed give away, among innumerable others.

I realized once I was in the "optimizations that dont need rust" section. Specifically "This is concurrency, not language magic."

I used to rely on this, and still mostly do - but you’d be surprised how quickly this has entered the normal vernacular! I hear people using it in conversation unprompted all the time.

Re: How uv got so fast

#268

Post by zahlman »

oefrha wrote: post #242
zahlman wrote: post #237

Earlier quoted context omitted.

> the selling point with the most traction is that you don't already need a working python install to get UV. And once you have UV, you can just go! I still genuinely do not understand why this is a serious selling point. Linux systems commonly already provide (and heavily depend upon) a Python distribution which is perfectly suitable for creating virtual environments, and Python on Windows is provided by a tradition…

Linux systems commonly already provide an outdated system Python you don’t want to use, and it can’t be used to create a venv of a version you want to use. A single Python version for the entire system fundamentally doesn’t work for many people thanks to shitty compat story in the vast ecosystem. Even languages with great compat story are moving to support multi-toolchains natively. For instance, go 1.22 on Ubuntu 24…

> 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 wide range of platforms, and all the most popular projects succeed. Try adding `--only-binary=:all:` to your pip invocations and let me know the next time that actually causes a failure.

Besides which, I was very specifically talking about the user story for people who are just learning to program and will use Python for it. Because otherwise this problem is trivially solved by anyone competent. In particular, building and installing Python from source is just the standard configure / make / make install dance, and it Just Works. I have done it many times and never needed any help to figure it out even though it was the first thing I tried to build from C source after switching to Linux.

Re: How uv got so fast

#269

Post by codeflo »

WD-42 wrote: post #214
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,…

I don't know what you think "typical Foss projects" are but in my experience they are exactly like your systemd example: one person that does what they want and share it with the world. The rest of your argument doesn't really make any sense with that in mind.

That's no longer as true as it once was. I get the feeling that quite a few people would consider "benevolent dictator for life" an outdated model for open source communities. For better or worse, there's a lot of push to transition popular projects towards being led by committee. Results are mixed (literally: I see both successes and failures), but that doesn't seem to have any effect on the trend.

Re: How uv got so fast

#270

Post by zahlman »

fragmede wrote: post #251
zahlman wrote: post #236

Earlier quoted context omitted.

Sorry, but that is simply incorrect, on many levels. Virtual environments are the fundamental way of setting up a Python project, whether or not you use uv, which creates and manages them for you . And these virtual environments can freely either use or not use the system environment, whether or not you use uv to create them. It's literally a single-line difference in the `pyvenv.cfg` file, which is a standard requir…

> 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.
Post reply on HN