[zbentley]

It works well. I didn’t know what language it was written in, nor did I care, until months after starting to use uv. I still don’t care.

Sure, it’s a bit silly (I don’t think I’d go as far as “pathetic”, just silly) that the implementation language is above the fold in the description/readme. That’s a cosmetic gripe; it’s still a good tool.

Rust or not, writing a tool to manage installation of a language platform in something other than the language it manages is a good idea, it avoids bootstrap problems. Using something statically-ish linked is also good; it avoids problems caused by the bootstrap dependencies. Tools like pyenv have taught us that shell is a poor choice of bootstrap language. Rust seems as good a choice as any given that.

[lunias]

The humorous thing to me is how keenly aware of performance issues w/ Python the community is, but they continue to trudge along with it and develop tooling to support their Python efforts in other languages (C, Rust, Java, etc.) instead of just writing the entire program in another language.

[zbentley]

Nothing in my post is about performance (of Python, Rust, or anything else).

While e.g. numpy might support your claim that Python being slow is reason to abandon it, I don’t think uv does.

My understanding is that the poor performance of pip is due to two things: a combination of slow-in-any-language solver and query/probe behavior that they’re stuck with for backwards compatibility reasons, and very poorly parallelized network and disk IO.

Parallel IO and better disk cache behavior are options because uv is a new system not tied to pip’s behavior and expectations, not because uv is a new system in rust.

Again, I think Rust is a fine choice here with some strengths in the dev-tools area, but those strengths are not (opinion, based on poking through a fair amount of uv’s code and reading Astral blog posts) the reason for uv’s success. The behavior choices that make it good are well supported in most languages.