←back to thread

uv: An extremely fast Python package and project manager, written in Rust

(github.com)
741 points chirau | 1 comments | 23 Jun 25 16:27 UTC | HN request time: 0.403s | source
Show context
theLiminator ◴[23 Jun 25 17:43 UTC] No.44358222[source]▶
uv and ruff are a great counterexample to all those people who say "never reinvent the wheel". Don't ever do it just for the sake of doing it, but if you have focused goals you can sometimes produce a product that's an order of magnitude better.
replies(7): >>44358352 #>>44358435 #>>44358583 #>>44358604 #>>44360352 #>>44361046 #>>44362201 #
eviks ◴[23 Jun 25 17:58 UTC] No.44358352[source]▶
They didn't reinvent the wheel, "just" replaced all the wood with more durable materials to make it handle rotation at 10 times the speed
replies(2): >>44358809 #>>44360563 #
socalgal2 ◴[23 Jun 25 18:48 UTC] No.44358809[source]▶
I'd be curious to know exactly what changed. Python -> Rust won't make network downloads faster nor file I/O faster. My naive guess is that all the speed comes from choosing better algorithms and/or parallelizing things. Not from Python vs Rust (though if it's hard to parallelize in Python and easy in rust that would certainly make a difference)
replies(7): >>44358971 #>>44359017 #>>44359201 #>>44359347 #>>44359610 #>>44359914 #>>44360074 #
1. the8472 ◴[23 Jun 25 19:05 UTC] No.44358971[source]▶
NVMe hungers, keeping it fed is hard work. Doing some serial read, decompress, checksum, write loop will leave if starved (QD<1) whenever you're doing anything but the last step. Disk IO isn't async unless you use io_uring (well ok, writeback caches can be). So threads are almost a must to keep NVMe busy. Conversely, waiting for blocking IO (e.g. directory enumeration) will keep your CPU starved. Here too the answer is more threads.