Honestly though it's a pretty rough indictment of Python that the best thing to happen in a decade is that people started writing Python tools in Rust. Not even a little Rust, uv is 98% Rust. I mean, they just released 3.14 and that was supposed to be a pretty big deal.
I sometimes wonder if many core Python people don’t actually like the language that much. That’s why (a) they’re constantly reinventing it, and (b) they celebrate rewrites from Python into other languages. Long before Rust, it was considered a good thing when a standard library module was rewritten in C.
Compare this to the Go community, who celebrate rewrites from other languages into Go. They rewrote their compiler in Go even though that made it worse (slower) than the original C version, because they enjoy using their own language and recognise the benefits of dogfooding.
This isn't really a fair comparison, though.
Python is an interpreted scripting language that was not originally designed with high performance computing in mind. It's perfectly normal for languages like that to have their tooling written in a systems programming language. It's also perfectly normal for languages like that to have components that do need to be performant written in a systems programming language. We call this, "Using the right tool for the job."
It's true that a lot of historical Python toolchain was written in Python. That was also using the right tool for the job. It's a holdover from a time when Python was still mostly just a scripting language, so projects were smaller and packages were smaller and dependency trees were smaller and there just generally weren't as many demands placed on the toolchain.
Go, by contrast, is itself a systems programming language. And so naturally they'd want to have all the systems components written in Go, and the sooner the better. It wouldn't inspire much confidence if the maintainers of a systems programming language didn't trust it with systems programming tasks.
The Python community has always had a make it work first, then optimize the parts that most benefit attitude, and has always seen selective use of lower-level systems languages as one (but far from the only) important tool for the optimize part.
I wouldn't describe having a culture that isn’t exclusivisy fanaticism as not liking the language, though.
only people who dont like python celebrate this kind of changes.
No, the "best thing that happened" (in TFA's author's opinion) is that this specific tool exists, with its particular design. Rust is an implementation detail. Most of the benefit that Uv offers over pip, in my analysis, is not a result of being written in Rust.
3.14 is a big deal.
I don't think Rust is incidental here. First, uv's particular design cargo culted from... well cargo. Which, they should be cause cargo is a great tool, no shade there.
But otherwise, people on this forum and elsewhere are praising uv for: speed, single-file executable, stability, and platform compatibility. That's just a summary of the top reasons to write in Rust!
I agree 3.14 is a big deal as far as Python goes, but it doesn't really move the needle for the language toward being able to author apps like uv.
Who cares what it is written in?
It's called dogfooding -- writing tools for the language in the language. Not doing so here, where the result is "best thing to happen to the ecosystem in a decade", is a tacit admission that Python isn't up for the task of writing best-in-class Python tooling (the use of Rust wasn't incidental). Having seen uv, people will probably start writing more Python-ecosystem projects in Rust.
Which is fine, Python is not for everything.
Rust's rigorous separation of immutable and mutable state consistently leads to higher-quality software that stands the test of time.
C has stood a very great test of time and we don't ascribe virtue to it.