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

351–360 of 468 posts

Re: How uv got so fast

#351

Post by optionalsquid »

zahlman wrote: post #241
collinmanderson wrote: post #165

Earlier quoted context omitted.

> the conversation here keeps collapsing back to "Rust rewrite good/bad." That feels like cargo-culting the toolchain instead of asking the uncomfortable question: why did it take a greenfield project to give Python the package manager behavior people clearly wanted for the last decade? I think there's a few things going on here: - If you're going have a project that's obsessed with speed, you might as well use rust/…

> the entire python ecosystem generally does not put much emphasis on startup time. You'd think PyPy would be more popular, then. > even modules in the standard library will pre-compile regular expressions at import time, even if they're never used, like the "email" module. Hmm, that is slower than I realized (although still just a fraction of typical module import time): $ python -m timeit --setup 'import re' 're.co…

> You'd think PyPy would be more popular, then.

PyPy is hamstrung by a limited (previously, a lack of) compatibility with compiled Python modules. If it had been a drop-in replacement for the equivalent Python versions, then it'd probably have been much more popular

Re: How uv got so fast

#352

Post by collinmanderson »

pnt12 wrote: post #280
zahlman wrote: post #248

Earlier quoted context omitted.

There are a handful of things in TFA that, while not outright false, are sloppy enough that I'd expect someone knowledgeable to know/explain better.

I didn't notice that - can you give some examples?

Some issues I noticed were:

> PEP 658 went live on PyPI in May 2023. uv launched in February 2024. uv could be fast because the ecosystem finally had the infrastructure to support it. A tool like uv couldn’t have shipped in 2020. The standards weren’t there yet.

In 2020 you could still have a whole bunch of performance wins before the PEP 658 optimization. There's also the "HTTP range requests" optimization which is the next best thing. (and the uv tool itself is really good with "uv run" and "uv python".)

> What uv drops: Virtual environments required. pip lets you install into system Python by default. uv inverts this, refusing to touch system Python without explicit flags. This removes a whole category of permission checks and safety code.

pip also refuses to touch system Python without explicit flags?

For uv, there are flags that allow it, so it doesn't really "removes a whole category of permission checks and safety code"? uv has "permission checks and safety code" to check if it's system python? I don't think uv has "dropped" anything here.

> Optimizations that don’t need Rust: Python-free resolution. pip needs Python running to do anything.

This seems to me to be implying that python is inherently slow, so yes, this optimization requires a faster language? Or maybe I don't get the full point.

> Where Rust actually matters: No interpreter startup. ... uv is a single static binary with no runtime to initialize.

This one's pretty petty/pedantic, but "Rust technically has a very lightweight runtime." https://users.rust-lang.org/t/does-rust-have-a-runtime/11406...

Re: How uv got so fast

#353

Post by Aurornis »

weitendorf wrote: post #316
codeflo wrote: post #269

Earlier quoted context omitted.

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.

Only a very, very small fraction of open source projects get to the point where they legitimately need committees and working groups and maintainer politics/drama. > quite a few people would consider "benevolent dictator for life" an outdated model for open source communities. I think what most people dislike are rugpulls and when commercial interests override what contributors/users/maintainers are trying to get out…

> Only a very, very small fraction of open source projects get to the point where they legitimately need committees and working groups and maintainer politics/drama.

You’re not wrong, but those are the projects we’re talking about in this thread. uv has become large enough to enter this realm.

> Bottom line is, BDFL works when 1. you aren't asking people to bet their business on you staying benevolent 2. you remain benevolent.

That second point is doing a lot of heavy lifting. All of the BDFL models depend on that one person remaining aligned, interested, and open to new ideas. A lot of the small projects I’ve worked with have had BDFL models where even simple issues like the BDFL becoming busy or losing interest became the death knell of the project. On the other hand, I can think of a few committee-style projects where everything collapsed under infighting and drama from the committee.

Re: How uv got so fast

#354

Post by twoodfin »

yunohn wrote: post #277
fleebee wrote: post #54

Earlier quoted context omitted.

You're probably right about the latter point, but I do wonder how hard it'd be to mask the default "marketing copywriter" tone of the LLM by asking it to assume some other tone in your prompt. As you said, reading this stuff is taxing. What's more, this is a daily occurrence by now. If there's a silver lining, it's that the LLM smells are so obvious at the moment; I can close the tab as soon as I notice one.

It’s definitely partially solved by extensive custom prompting, as evidenced by sibling comments. But that’s a lot of effort for normal users and not a panacea either. I’d rather AI companies introduce noise/randomness themselves to solve this at scale.

I don’t think that’s a solution.

The problem isn’t the surface tics—em dashes, short exclamatory sentences, lists of three, “Not X: Y!”.

Those are symptoms of the deep, statistically-built tissue of LLM “understanding” of “how to write a technical blog post”.

If you randomize the surface choices you’re effectively running into the same problem Data did on Star Trek: The Next Generation when he tried to get the computer to give him a novel Sherlock Holmes mystery on the holodeck. The computer created a nonsense mishmash of characters, scenes, and plot points from stories in its data bank.

Good writing uses a common box of metaphorical & rhetorical tools in novel ways to communicate novel ideas. By design, LLMs are trying to avoid true (unpredictable) novelty! Thus they’ll inevitably use these tools to do the reverse of what an author should be attempting.

Re: How uv got so fast

#355

Post by kibwen »

TheDong wrote: post #297
pnt12 wrote: post #279

Earlier quoted context omitted.

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

I'm not sure if it even makes sense for a TOML file to be "read incrementally", because of the weird feature of TOML (inherited from INI conventions) that allow tables to be defined in a piecemeal, out-of-order fashion. Here's an example that the TOML spec calls "valid, but discouraged":

    [fruit.apple]
    [animal]
    [fruit.orange]
So the only way to know that you have all the keys in a given table is to literally read the entire file. This is one of those unfortunate things in TOML that I would honestly ignore if I were writing my own TOML parser, even if it meant I wasn't "compliant".

Re: How uv got so fast

#356

Post by fluorinerocket »

jacquesm wrote: post #331
aragilar wrote: post #306

Earlier quoted context omitted.

Honestly, they should be using conda (if they're working on their laptops) and the cluster package manager otherwise.

Conda has slowly but surely gone down the drain as well. It used to be bullet proof but there too you now get absolutely unsolvable circular dependencies.

I haven't ever experienced this yet, what packages were involved?

Re: How uv got so fast

#357

Post by CamouflagedKiwi »

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

They can be a bit long in the tooth, yes, but from past experience another Python version I don't want to use is anything ending in .0, so I can cope with them being a little older.

That's in quite a bit of contrast to something like Go, where I will happily update on the day a new version comes out. Some care is still needed - they allow security changes particularly to be breaking, but at least those tend to be deliberate changes.

Re: How uv got so fast

#358

Post by panzi »

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

Since uv and systemd are both FOSS how are they not part of the FOSS world?

Re: How uv got so fast

#359

Post by hk1337 »

Onavo wrote: post #178
hk1337 wrote: post #137

It’s fast because it sucks the life force from bad developers to make them into something good. Jokes aside… I really like uv but also really like mise and I cannot seem to get them to work well together.

Why? They are pretty compatible. Just set the venv in the project's mise.toml are you are good to go. Mise will activate it automatically when you change into the project directory.

I believe I was trying it the other way around. I installed uv and python with mise but uv still created a .python_version file and using the one installed in the system instead of what was in mise

Re: How uv got so fast

#360

Post by jacquesm »

fluorinerocket wrote: post #356
jacquesm wrote: post #331

Earlier quoted context omitted.

Conda has slowly but surely gone down the drain as well. It used to be bullet proof but there too you now get absolutely unsolvable circular dependencies.

I haven't ever experienced this yet, what packages were involved?

Good question, I can't backtrack right now but it was apmplanner that I had to compile from source, and it contains some python that gets executed during the build process (I haven't seen it try to run it during normal execution yet).

Probably either one of python-serial python-pexpect judging by the file dates, and neither of these are so exciting that there should have been any version conflicts at all.

And the only reason I had to rebuild it at all was due to another version conflict in the apm distribution that expects a particular version of pixbuf to be present on the system and all hell breaks loose if it isn't, and you can't install that version on a modern system because that breaks other packages.

It is insane how bad all this package management crap is. The GNU project and the linux kernel are the only ones that have never given me any trouble.

Post reply on HN