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.
I feel like this is conflating two questions now.
- Whether to use a non-Python language where appropriate
- Whether to use rust over C, which is already heavily used and fundamental in the ecosystem (I think we can put cython and Fortran to the side)
I think these questions are mostly independent.
If the chief criterion is accessibility to the Python user base, issue 2 isn’t a problem IMO. One could argue, as does @eraclito@feddit.it in this thread, that in fact rust provides benefits along these lines that C doesn’t. Rust being influenced by Python adds weight to that. Either way though, people like and want to program in rust and have provided marked success so far in the Python ecosystem (as eraclito cites). It’s still a new-ish language, but if the core issue is C v Rust, it’s probably best to address it on those terms.
I think for python tooling the choice is Python Vs Rust. C isn’t in the mix either.
people like and want to program in rust
I think there’s a survivor bias going on here. Those that have tried rust and stuck with it, they also like it. Far more people in the python community haven’t tried it, or have and not stuck with it. I like and want to program Haskell. I’m not going to write python tools in it because the community won’t appreciate it.
Tools should be maintained by those that use them. Python doesn’t want to rely on the portion of the venn diagram that are rust and python users because that pool of people is much smaller.
