Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I am totally against Python tooling being written in a language other than Python

I will be out enjoying the sunshine while you are waiting for your Pylint execution to finish



Linting is the new "compiling!"


Linting and type checking are very CPU intensive tasks so I would excuse anyone implementing those types of tools in $LANG where using all CPU juice matters.

I can't help but think uv is fast not because it's written in Rust but because it's a fast reimplementation. Dependency solving in the average Python project is hardly computationally expensive, it's just downloading and unpacking packages with a "global" package cache. I don't see why uv couldn't have been implemented in Python and be 95% as fast.

Edit: Except implementing uv in Python requires shipping a Python interpreter kinda defeating some of it's purpose of being a package manager able to install Python as well.


Nope, this is totally an area where using Rust makes sense and is just _fast_. The fact that Rust has concurrency primitives that are easy to use helps tons too.


I still don't get it, uv is checking if dependencies exist on disk, if they do it creates a link from the cache to your environment, it's a stat syscall and a hardlink syscall in the best of worlds (after solving dependency versions but that should already be done in a lockfile).

Interpreter startup time is hardly significant once in one invocation to set up your environment.

What makes Rust faster for downloading and unpacking dependencies. Considering how slow pip is and how fast uv is (100s of X) it seems naive to attribute it to the language.


You also have to factor in startup time and concurrency. Caching an SAT solvers can't get python to 95% of uv.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: