| ▲ | blundergoat 8 hours ago |
| The real win here isn't TS over Rust, it's the O(N²) -> O(N) streaming fix via statement-level caching. That's a 3.3x improvement on its own, independent of language choice. The WASM boundary elimination is 2-4x, but the algorithmic fix is what actually matters for user-perceived latency during streaming. Title undersells the more interesting engineering imo. |
|
| ▲ | azakai 6 hours ago | parent | next [-] |
| O(N²) -> O(N) was 3.3x faster, but before that, eliminating the boundary (replacing wasm with JS) led to speedups of 2.2x, 4.6x, 3.0x (see one table back). It looks like neither is the "real win". both the language and the algorithm made a big difference, as you can see in the first column in the last table - going to wasm was a big speedup, and improving the algorithm on top of that was another big speedup. |
|
| ▲ | nulltrace 5 hours ago | parent | prev | next [-] |
| Yeah the algorithmic fix is doing most of the work here. But call that parser hundreds of times on tiny streaming chunks and the WASM boundary cost per call adds up fast. Same thing would happen with C++ compiled to WASM. |
|
| ▲ | catlifeonmars 2 hours ago | parent | prev | next [-] |
| You’re not wrong, but that win would not get as many views. It’s not clickbaity enough |
|
| ▲ | socalgal2 7 hours ago | parent | prev | next [-] |
| same for uv but no one takes that message. They just think "rust rulez!" and ignore that all of uv's benefits are algo, not lang. |
| |
| ▲ | estebank 6 hours ago | parent | next [-] | | Some architectures are made easier by the choice of implementation language. | | |
| ▲ | EdwardDiego an hour ago | parent | next [-] | | UV also has the distinct advantage in dependency resolution that it didn't have to implement the backwards compatible stuff Pip does, I think Astral blogged on it. If I can find it, I'll edit the link in. edit wasn't Astral, but here's the blog post I was thinking of. https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html That said, your point is very much correct, if you watch or read the Jane Street tech talk Astral gave, you can see how they really leveraged Rust for performance like turning Python version identifiers into u64s. | |
| ▲ | crubier 5 hours ago | parent | prev [-] | | In my experience Rust typically makes it a little bit harder to write the most efficient algo actually. | | |
| |
| ▲ | rowanG077 6 hours ago | parent | prev [-] | | That's a pretty big claim. I don't doubt that a lot of uv's benefits are algo. But everything? Considering that running non IO-bound native code should be an order of magnitude faster than python. | | |
| ▲ | jeremyjh 5 hours ago | parent | next [-] | | Its a pretty well-supported claim. uv skips doing a number of things that generate file I/O. File I/O is far more costly than the difference in raw computation. pip can't drop those for compatibility reasons. https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html | | |
| ▲ | staticassertion 9 minutes ago | parent | next [-] | | Do you actually believe that UV would be as fast if it were written in Python? | |
| ▲ | rowanG077 5 hours ago | parent | prev [-] | | I don't think the article you linked supports the claim that none of UV performance improvements are related to using rust over python at all. In fact it directly states the exact opposite. They have an entire section dedicated to why using Rust has direct performance advantages for UV. | | |
| ▲ | jeremyjh 3 hours ago | parent [-] | | What it says is this: > uv is fast because of what it doesn’t do, not because of what language it’s written in. The standards work of PEP 518, 517, 621, and 658 made fast package management possible. Dropping eggs, pip.conf, and permissive parsing made it achievable. Rust makes it a bit faster still. | | |
| ▲ | rowanG077 3 hours ago | parent [-] | | Yes exactly! That quote directly disproves that all of the improvements UV has over competitors is because of algos, not because of rust. So the claim is not well supported at all by the article as you stated, in fact the claim is literally disproven by the article. | | |
| ▲ | jeremyjh 3 hours ago | parent | next [-] | | You are right. 99% is not 100%. | | |
| ▲ | rowanG077 2 hours ago | parent [-] | | I don't think the article has substantive numbers. You'd have to re-implement UV in python to do that. I don't think anyone did that. It would be interesting at least to see how much UV spends in syscalls vs PIP and make a relative estimate based on that. |
| |
| ▲ | kyralis 2 hours ago | parent | prev [-] | | This is either an overly pedantic take or a disingenuous one. The very first line that the parent quoted is > uv is fast because of what it doesn’t do, not because of what language it’s written in. The fact that the language had a small effect ("a bit") does not invalidate the statement that algorithmic improvements are the reason for the relative speed. In fact, there's no reason to believe that rust without the algorithmic version would be notably faster at all. Sure, "all" is an exaggeration, but the point made still stands in the form that most readers would understand it: algorithmic improvements are the important difference between the systems. | | |
| ▲ | rowanG077 an hour ago | parent [-] | | I think we might be talking past each other a bit. The specific claim I was responding to was that all of uv’s performance improvements come from algorithms rather than the language. My point was just that this is a stronger claim than what the article supports, the article itself says Rust contributes “a bit” to the speed, so it’s not purely algorithmic. I do agree with the broader point that algorithmic and architectural choices are the main reason uv is fast, and I tried to acknowledge that, apparently unsuccessfully, in my very my first comment (“I don't doubt that a lot of uv's benefits are algo. But everything?”). |
|
|
|
|
| |
| ▲ | thfuran 5 hours ago | parent | prev [-] | | More than one, I'd think. |
|
|
|
| ▲ | adastra22 16 minutes ago | parent | prev | next [-] |
| No AI generated comments on HN please. |
|
| ▲ | Aurornis 7 hours ago | parent | prev | next [-] |
| > Title undersells the more interesting engineering imo. Thanks for cutting through the clickbait. The post is interesting, but I'm so tired of being unnecessarily clickbaited into reading articles. |
|
| ▲ | sroussey 7 hours ago | parent | prev | next [-] |
| Yeah, though the n^2 is overstating things. One thing I noticed was that they time each call and then use a median. Sigh. In a browser. :/ With timing attack defenses build into the JS engine. |
| |
| ▲ | fn-mote 6 hours ago | parent [-] | | For those of us not in the know, what are we expecting the results of the defenses to be here? | | |
| ▲ | sroussey an hour ago | parent [-] | | Jitter. It make precise timings unreliable. Time the entire time of 1000 runs and divide by 1000 instead of starting and stopping 1000 timers. |
|
|
|
| ▲ | shmerl 7 hours ago | parent | prev [-] |
| More like a misleading clickbait. |
