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.

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.

WASM boundary overhead is only half the story. Once you start bouncing tiny chunks across JS and WASM over and over, the data shuffling and memory layout mismatch can trash cache behavior, pile on allocation churn, and turn a nice benchmark into something that looks nothing like a parser living inside a streaming pipeline. That's why most 'language duel' posts feel beside the point.

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.

Some architectures are made easier by the choice of implementation language.

In my experience Rust typically makes it a little bit harder to write the most efficient algo actually.

That’s usually ok bc in most code your N is small and compiler optimizations dominate.

Would you be willing to give an example of this?

Not OP, but one example where it is a bit harder to do something in Rust that in C, C++, Zig, etc. is mutability on disjoint slices of an array. Rust offers a few utilities, like chunks_by, split_at, etc. but for certain data structures and algorithms it can be a bit annoying.

It's also worth noting that unsafe Rust != C, and you are still battling these rules. With enough experience you gain an understanding of these patterns and it goes away, and you also have these realy solid tools like Miri for finding undefined behavior, but it can be a bit of a hastle.

Has no one written a python! macro for this use case?

Mutating tree structures tends to be a fiddle (especially if you want parent pointers).

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.

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.

More than one, I'd think.

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

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.

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.

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.

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.

You are glossing over the fact that the original statement I was commenting on was literally that ALL improvements UV has are due to algorithms and not due to rust.

So this:

> The statement that algorithmic improvements are the reason for the relative speed.

Was not at all the statement that I was attacking. For one because I don't disagree with that statement. I even point to this in my very first comment:

> I don't doubt that a lot of uv's benefits are algo. But everything?

You and the other person are trying to pull a classic motte and bailey. Attempting to make it look as if I'm attacking the very reasonable position that algorithms are the bulk of the improvements why UV is fast.

You are being very pedantic here.

You are right. 99% is not 100%.

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.

Do you actually believe that UV would be as fast if it were written in Python?

It would come pretty close, probably close enough that you wouldn't be able to tell the difference on 90% of projects.

Vague. What's pretty close? I mean, even for IO bound tasks you can pretty quickly validate that the performance between languages is not close at all.

Sure, within 100ms. Who cares what the performance multiples are?

That literally makes no sense. 100ms... out of what? Is it 1ms vs 100ms? 100000ms vs 100100ms?

Anyway, dubious claim since a Python interpreter will take 10s of milliseconds just to print out its version.

Do you have any evidence? I can point at techempower benchmarks showing IO bound tasks are still 10-100x faster in native languages vs Python/JS.

I'm saying that the Rust might execute in 50ms and the Python in 150ms. You are the one not making sense, we are talking about application performance, why are you not measuring that in milliseconds.

That is assuming Rust is 100x faster than Python btw, 49ms of I/O, 1ms of Rust, 100ms of Python.

> I'm saying that the Rust might execute in 50ms and the Python in 150ms.

Okay, so the Rust code would be 3x as fast. Feels arbitrary, but sure.

> You are the one not making sense, we are talking about application performance, why are you not measuring that in milliseconds.

I explained why your post made no sense already...

> That is assuming Rust is 100x faster than Python btw, 49ms of I/O, 1ms of Rust, 100ms of Python.

That's not how anything works. Different languages will perform differently on IO work, different runtimes will degrade under IO differently, etc. That's why even basic echo HTTP servers perform radically differently in Python vs Rust.

This isn't how computers work and it's not even how math works.

This conversation has become nonsensical. The thing we can agree with is this - no, uv would not be as fast if it were written in Python.

> That's not how anything works. Different languages will perform differently on IO work, different runtimes will degrade under IO differently, etc. That's why even basic echo HTTP servers perform radically differently in Python vs Rust.

> This isn't how computers work and it's not even how math works.

What are you disagreeing with? There's some baseline amount of I/O that the kernel does for you, that's what I'm assuming is 50ms, and everything else like runtime degrading is overhead due to the language/platform choice. I'm saying Rust is upwards of 100x faster in that regard thanks to its zero cost abstraction philosophy. You can't just include the I/O baseline in a claim about Rust's performance advantage. You'll be really disappointed when Rust doesn't download your files 100x as fast as the Python file downloader.

Anyway, I'm sorry I provoked your antagonism with my terse messages, I wasn't trying to be blase. I believe uv is the sort of tool that wouldn't suffer much from the downsides of Python and that in most situations the reduced runtime overhead of Rust would have a negligible impact on the user experience. I'm not arguing that they shouldn't build uv in Rust. Most situations is not all situations, and when a tool is used so widely you'll hit all edge cases, from the point where the 10s of milliseconds of startup time matters to the point where Pythons I/O overhead matters at scale.

I think a missing piece here is that you think that Rust won't download a file faster than Python but it absolutely can. This seems to just be a misconception people have about IO, like "download a file" is a thing that exists wholly outside of your process.

I know it can, but it can't download it faster than the network card can write it into its buffers. That's the part I would count as the 50ms that both can't improve upon.

Of course. But why would that matter if Python can't get there to begin with? You're not going to hit NIC bottlenecks with Python, not without a ton of work and tradeoffs at least.

> Different languages will perform differently on IO work,

IO is executed by kernel, file system or network drivers. IO performance is not dependent at all on which language makes the syscalls.

> The thing we can agree with is this - no, uv would not be as fast if it were written in Python.

In this thread, we are talking about the speed of uv in terms of user experience - how long a person waits for command line operations to complete. Things that pip takes multiple seconds to do, uv will do in dozens of milliseconds. If uv were written in python, it would take dozens of ms + a few dozens more, which means absolutely fuck all nothing in the context of the thousands of milliseconds saved over pip.

Its possible a user might perceive a slight difference in larger projects, but if pip had been uv-but-in-python, the uv-in-rust project would never have been started in the first place because no one would have bothered switching.

> This conversation has become nonsensical.

Agreed. No one in this thread is disputing that Rust code is faster than Python, only that in this case it is completely insignificant in the face of all the useless file and network I/O that pip is doing, and uv is not.

> IO is executed by kernel, file system or network drivers. IO performance is not dependent at all on which language makes the syscalls.

I think your posts on this topic can not possibly be worth responding to if you're coming to the conversation with this level of not understanding things.

Your post is a combination of not understanding computers and then hand waving about fake numbers and user expectations. IO is not magic, it is not some distinct process that you have no control over from userland, it is exactly the sort of thing that Python does very poorly at, in fact.

I'll just reference techempower again, or you can look up those system calls you referenced like how epoll works and then look into what is involved for Python to use epoll effectively.

Just the fact that I can install a single binary is 10x better than an equally fast Python implementation.

> 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.

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.

For those of us not in the know, what are we expecting the results of the defenses to be here?

Jitter. It make precise timings unreliable. Time the entire time of 1000 runs and divide by 1000 instead of starting and stopping 1000 timers.

More like a misleading clickbait.

You’re not wrong, but that win would not get as many views. It’s not clickbaity enough

No AI generated comments on HN please.

> The real win here isn't TS over Rust

Kinda is. We came up with abstractions to help reason about what really matters. The more you need to deal with auxillary stuff (allocations, lifetimes), more likely you will miss the big issue.

The opposite: the more you rely on abstractions the more you miss the lower level optimization opportunities and loose understanding of algorithms and hardware.

> of algorithms

Yes, sprinkling your code logic with malloc, .clone() or lifetime annotations on the other hand brings algorithmic enlightenment.

Dealing and having to think about the cost of malloc, clone() and lifetimes, brings algorithmic enlightenment more than working on an high abstraction ivory tower where things "magically happen".

Is your argument that the average Python or Typescript dev gets to think and care more about algorithms than the average C/C++/Rust dev?

They even directly conclude at the end of the article that improvements in algorithm are more important than the choice of language:

> Algorithmic complexity improvements dominate language-level optimisations. Going from O(N²) to O(N) in the streaming case had a larger practical impact than switching from WASM to TypeScript.

Yet they still have chosen to put the “Rust rewrite” part in the title. I almost think it's a click bait.