Python 3.14(astral.sh) |
Python 3.14(astral.sh) |
(13 points, 18 hours ago, 3 comments) https://news.ycombinator.com/item?id=45502533
(37 points, 16 hours ago, 6 comments) https://news.ycombinator.com/item?id=45503617
(20 points, 12 hours ago, 10 comments) https://news.ycombinator.com/item?id=45507449
$ uvx python@3.14
Python 3.14.0 (main, Oct 7 2025, 15:35:21) [Clang 20.1.4 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
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.
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.