Jacob Kaplan-Moss kicked off this fascinating conversation about [uv](https://docs.astral.sh/uv/) on Mastodon recently. It's worth reading the whole thing, which includes input from a whole range of influential Python community members …
Fair, but at some point the “dream” breaks down. Python itself is written in C and plenty of packages, some vital, rely on C or Cython (or fortran) and rust now more and more. So why not the tooling that’s used all the time and doing some hard work and often in build/testing cycles?
If Guido had packaging and project management included in the standard library from ages ago, with parts written in C, no one would bat an eye lid whether users could contribute to that part of the system. Instead, they’d celebrate the “batteries included”, “ease of use” and “zen”-like achievements of the language.
Somewhere in Simon’s blog post he links to a blog post by Armin on this point, which is that the aim is to “win”, to make a singular tool that is better than all the others and which becomes the standard that everyone uses so that the language can move on from this era of chaos. With that motive, the ability for everyday users to contribute is no longer a priority.
C is the implementation language of Python and is always going to be there.
Cython is a very similar language to Python and designed to be very familiar to Python writers.
Fortran is the language that BLAS and similar libraries were historically implemented in since the 70s. Nobody in the python community has to write Fortran today. Those libraries are wrapped.
Rust is none of the above. Bringing it into the mix adds a new barrier.
Or new possibilities… See: UV, pixi, hatch, ruff, polar, pyarrow, pydantic, data fusion, deltalake, fastuuid, granian, Robyn…
I’m not a c expert and I’m not comfortable in writing python extensions in C…
But with rust you have the compiler that, if you constraint yourself to the safe part of the rust language, is checking for you for several stupid issues. In rust, I can focus on fixing logical and other implementation errors. Coming from python I feel much more at home with rust (async, yield, iterator, generator, closure, match, walrus, etc) than with C.
Fair, but at some point the “dream” breaks down. Python itself is written in C and plenty of packages, some vital, rely on C or Cython (or fortran) and rust now more and more. So why not the tooling that’s used all the time and doing some hard work and often in build/testing cycles?
If Guido had packaging and project management included in the standard library from ages ago, with parts written in C, no one would bat an eye lid whether users could contribute to that part of the system. Instead, they’d celebrate the “batteries included”, “ease of use” and “zen”-like achievements of the language.
Somewhere in Simon’s blog post he links to a blog post by Armin on this point, which is that the aim is to “win”, to make a singular tool that is better than all the others and which becomes the standard that everyone uses so that the language can move on from this era of chaos. With that motive, the ability for everyday users to contribute is no longer a priority.
Those languages bring different things though:
Python is the language the tool is for
C is the implementation language of Python and is always going to be there.
Cython is a very similar language to Python and designed to be very familiar to Python writers.
Fortran is the language that BLAS and similar libraries were historically implemented in since the 70s. Nobody in the python community has to write Fortran today. Those libraries are wrapped.
Rust is none of the above. Bringing it into the mix adds a new barrier.
Or new possibilities… See: UV, pixi, hatch, ruff, polar, pyarrow, pydantic, data fusion, deltalake, fastuuid, granian, Robyn…
I’m not a c expert and I’m not comfortable in writing python extensions in C…
But with rust you have the compiler that, if you constraint yourself to the safe part of the rust language, is checking for you for several stupid issues. In rust, I can focus on fixing logical and other implementation errors. Coming from python I feel much more at home with rust (async, yield, iterator, generator, closure, match, walrus, etc) than with C.