The former is subjective, but the latter seems like not really much of an issue compared to the language itself being written in C.
I have no aversion to Rust (I've read some of it, and while foreign, it comes across as much more pleasant than C or C++), but the way it's promoted often is grating. I'm getting really tired in particular of how the speed of Rust is universally described as "blazing", and how "written in Rust" has a sparkle emoji as mandatory punctuation. But maybe that's just because I'm, well, older than Python itself.
I don't really care that the reference implementation isn't self-hosting (although it's nice that PyPy exists). Using non-Python for support (other than IDEs - I don't care about those and don't see a need to make more of them at all) is a bit grating in that it suggests a lack of confidence in the language.
But much more importantly, when people praise uv, they seem to attribute everything they like about it to either a) the fact that it's written in Rust or b) the fact that it's not written in Python, and in a lot of cases it just doesn't stand up to scrutiny.
uv in particular is just being compared to a low bar. Consider: `pip install` without specifying a package to install (which will just report an error that you need to specify a package) on my machine takes almost half a second to complete. (And an additional .2 seconds with `--python`.) In the process, it imports more than 500 modules. Seriously. (On Linux you can test it yourself by hacking the wrapper script. You'll have to split the main() call onto a separate line to check in between that and sys.exit().)
[0] https://flet.dev
You can also write Cython for more perf oriented code but I can totally understand the value Rust brings to the table, it's just now another language you'll need to know or learn, more layers like maturin or pyO3, while cffi is just there.
All the tooling coming from astral is amazing and I use it everyday but I can see the increasing complexity of our toolchains, not in ergonomics (it's much better now) but the tools themselves.
But how often in your career have you actually done this?
Then you have PyPy which you’d have to accommodate somehow.
It doesn’t help that in a case where you have to build everything, Rust build toolchain currently needs Python. That sure would make bootstrapping a bitch if Python and Rust became a circular dependency of one another.
Adding pypy support to a pyo3 + maturin project was literally just a matter of telling maturin to build that wheel. And I added graal while at it.
Hopefully they eventually add stable ABI support too so I don’t have to add individual pypy/graal wheel targets.
Or pyo3 and maturin may support hpy once that’s stable.
I also modified a script I've been using for a few years to patch pylsp so it can now see uv script envs using the "uv sync --dry-run --script <path>" hack.
And so I wrote a patcher[1] that searches the project folder and parents until it finds an appropriate .env file, and uses it to resolve the path to the project's env. With the latest changes to the patcher it now uses the output from "uv sync", which is the path to a standalone script's env, as well as the traditional "source venv_path/bin/activate" pattern to resolve envs for uv-managed projects.
[0] https://github.com/hyperupcall/autoenv [1] https://gitlab.com/-/snippets/2279333