8 ms·

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 f

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.

eviks 1y ago
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
- socalgal2 1y ago
  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)
  - the8472 1y ago
    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.
  - jerpint 1y ago
    From just my observations they basically parallelized the install sequence instead of having it be sequential (among many other optimizations most likely)
  - ekidd 1y ago
    I've translated code from Ruby to Python, and other code from Rust to Python. Rust's speed advantages typically come from one of a few places: 1. Fast start-up times, thanks to pre-compiled native binaries. 2. Large amounts of CPU-level concurrency with many fewer bugs. I'm willing to do ridiculous threading tricks in Rust I wouldn't dare try in C++. 3. Much lower levels of malloc/free in Rust compared to some high-level languages, especially if you're willing to work a little for it. Calling malloc in a multithreaded system is basically like watching the Millennium Falcon's hyperdrive fail. Also, Rust encourages abusing the stack to a ridiculous degree, which further reduces allocation. It's hard to "invisibly" call malloc in Rust, even compared to a language like C++. 4. For better or worse, Rust exposes a lot of the machinery behind memory layout and passing references. This means there's a permanent "Rust tax" where you ask yourself "Do I pass this by value or reference? Who owns this, and who just borrows is?" But the payoff for that work is good memory locality. So if you put in a modest amount of effort, it's fairly easy to make Rust run surprisingly fast. It's not an absolute guarantee, and there are couple of traps for the unwary (like accidentally forgetting to buffer I/O, or benchmarking debug binaries).
  - physicsguy 1y ago
    The package resolution is a big part of it, it's effectively a constraint solver. I.e. if package A requires package B constrained between version 1.0 < X <= 2.X and Package B requires package C between... and so on and so on. Conda rewrote their package resolver for similar reasons
  - globular-toast 1y ago
    There is a talk about it from one of the authors here: https://www.youtube.com/watch?v=gSKTfG1GXYQ https://www.youtube.com/watch?v=gSKTfG1GXYQ tl;dw Rust, a fast SAT solver, micro-optimisation of key components, caching, and hardlinks/CoW.
  - captnswing 1y ago
    Extremely interesting presentation from Charlie Marsh about all the optimizations https://youtu.be/gSKTfG1GXYQ?si=CTc2EwQptMmKxBwG https://youtu.be/gSKTfG1GXYQ?si=CTc2EwQptMmKxBwG
    - socalgal2 1y ago
      Thanks. So from the video the biggest wins were 1. they way get the metadata for a package. packages are in zip files. zip files have their TOC at the end. So, instead of downloading the entire zip they just get the end of the file, read the TOC, then from that download just the metadata part I've written that code before for my own projects. 2. They cache the results of packages unzipped and then link into your environment This means there's no files being copied on the 2nd install. Just links. Both of those are huge time wins that would be possible in any language. 3. They store their metadata as a memory dump So, on loading there is nothing to parse. Admittedly this is hard (impossible?) in many languages. Certainly not possible in Python and JavaScript. You could load binary data but it won't be useful without copying it into native numbers/strings/ints/floats/doubles etc... I've done this in game engines to reduce load times in C/C++ and to save memory. It'd be interesting to write some benchmarks for the first 2. The 3rd is a win but I suspect the first 2 are 95% of the speedup.
  - jerf 1y ago
    It became a bit of a meme, especially in the web development space, that all programs are always waiting on external resources like networks, databases, disks, etc., and so scripting languages being slower than other languages doesn't matter and they'll always be as fast as non-scripting languages. Even on a single core, this turns out to be simply false. It isn't that hard to either A: be doing enough actual computation that faster languages are in fact perceptibly faster, even, yes, in a web page handler or other such supposedly-blocked computation or B: without realizing it, have stacked up so many expensive abstractions on top of each other in your scripting language that you're multiplying the off-the-top 40x-ish slower with another set of multiplicative penalties that can take you into effectively arbitrarily-slower computations. If you're never profiled a mature scripting language program, it's worth your time. Especially if nobody on your team has ever profiled it before. It can be an eye-opener. Then it turns out that for historical path reasons, dynamic scripting languages are also really bad at multithreading and using multiple cores, and if you can write a program that can leverage that you can just blow away the dynamic scripting languages. It's not even hard... it pretty much just happens. (I say historical path reasons because I don't think an inability to multithread is intrinsic to the dynamic scripting languages. It's just they all came out in an era when they could assume single core, it got ingrained into them for a couple of decades, and the reality is, it's never going to come fully out. I think someone could build a new dynamic language that threaded properly from the beginning, though.) You really can see big gains just taking a dynamic scripting language program and turning it into a compiled language with no major changes to the algorithms. The 40x-ish penalty off the top is often in practice an underestimate, because that number is generally from highly optimized benchmarks in which the dynamic language implementation is highly tuned to avoid expensive operations; real code that takes advantage of all the conveniences and indirection and such can have even larger gaps. This is not to say that dynamic scripting languages are bad. Performance is not the only thing that matters. They are quite obviously fast enough for a wide variety of tasks, by the strongest possible proof of that statement. That said, I think it is the case that there are a lot of programmers who have no idea how much performance they are losing in dynamic scripting languages, which can result in suboptimal engineering decisions. It is completely possible to replace a dynamic scripting language program with a compiled one and possibly see 100x+ performance improvements on very realistic code, before adding in multithreading. It is hard for that not to manifest in some sort of user experience improvement. My pitch here is not to give up dynamic scripting languages, but to have a more realistic view of the programming language landscape as a whole.
- doug_durham 1y ago
  A big part of the "magic" is that there is a team of paid professionals maintaining and improving it. That's more important than it being written in Rust. If uv were forked it would devolve to the level of pip over time.
0cf8612b2e1e 1y ago
The history of Python package management is clear that everyone thinks they can do a better job than the status quo.
- psunavy03 1y ago
  In this case, they were right.
  - dwattttt 1y ago
    I would say in many cases they were right; the history of Python package management is littered with winners as well as losers.
- henry700 1y ago
  Of course they do, this tends to happen when the history is it being hot flaming garbage.
- nickelpro 1y ago
  uv is purely a performance improvement, it changes nothing about the mechanics of Python environment management or packaging. The improvements came from lots of work from the entire python build system ecosystem and consensus building.
  - 0cf8612b2e1e 1y ago
    Disagree in that uv makes switching out the underlying interpreter so straightforward. Becomes trivial to swap from say 3.11 to 3.12. The pybi idea. Sure, other tools could handle the situation, but being baked into the tooling makes it much easier to bootstrap different configurations.
    - nickelpro 1y ago
      Yes, it's faster and better than pyenv, but the mechanism it's using (virtual environments) is not a uv invention. uv does the Python ecosystem better than any other tool, but it's still the standard Python ecosystem as defined in the relevant PEPs.
jjtheblunt 1y ago
> an order of magnitude better off topic, but i wonder why that phrase gets used rather than 10x which is much shorter.
- Scene_Cast2 1y ago
  10x is too precise.
- fkyoureadthedoc 1y ago
  - sounds cooler - 10x is a meme - what if it's 12x better
- refulgentis 1y ago
  "10x" has been cheapened / heard enough / de facto, is a more general statement than a literal interpretation would indicate. (i.e. 10x engineer. Don't hear that much around these parts these days) Order of magnitude faces less of that baggage, until it does :)
  - psunavy03 1y ago
    Would you say it faces . . . orders of magnitude less baggage?
- bxparks 1y ago
  I think of "an order of magnitude" as a log scale. It means somewhere between 3.16X and 31.6X.
  - jjtheblunt 1y ago
    yeah that's what i meant with 10x, like it's +1 on the exponent, if base is 10. but i'm guessing what others are thinking, hence the question.
    - bxparks 1y ago
      The problem is that 10x appears to be a linear scale. It could mean 9.5x to 10.5x if it's supposed to have 2 significant digits. Or it could be 5x to 15x if it meant to have 1 significant digit.
mort96 1y ago
Honestly "don't reinvent the wheel" makes absolutely no sense as a saying. We're not still all using wooden discs as wheels, we have invented much better wheels since the neolithic. Why shouldn't we do the same with software?
- aalimov_ 1y ago
  I always took this saying as meaning that we don’t re-invent the concept of the wheel. For example the Boring company and Tesla hoping to reinvent the concept of the bus/train.. (iirc your car goes underground on some tracks and you get to bypass traffic and not worry about steering) A metal wheel is still just a wheel. A faster package manager is still just a package manager.
  - haiku2077 1y ago
    That's not how I've ever seen it used in practice. People use it to mean "don't build a replacement for anything functional."
- haiku2077 1y ago
  Right, wheels are reinvented every few years. Compare tires of today to the ones 20 years ago and the technology and capability is very different, even though they look identical to a casual eye. My primary vehicle has off-road capable tires that offer as much grip as a road-only tire would have 20-25 years ago, thanks to technology allowing Michelin to reinvent what a dual-purpose tire can be!
  - nightpool 1y ago
    > Compare tires of today to the ones 20 years ago and the technology and capability is very different, even though they look identical to a casual eye Can you share more about this? What has changed between tires of 2005 and 2025?
    - haiku2077 1y ago
      In short: Better materials and better computational models. https://www.caranddriver.com/features/a15078050/we-drive-the-worlds-most-busted-out-bmw-m3-feature/ https://www.caranddriver.com/features/a15078050/we-drive-the... > In the last decade, the spiciest street-legal tires have nearly surpassed the performance of a decade-old racing tire, and computer modeling is a big part of the reason (written about 8 years ago)
CrendKing 1y ago
I believe most of the time this phrase is said to an inexperienced artisan who has no idea how the current system works, what's the shortcoming of it, and how to improve upon it. Think of an undergraduate student who tries to solve the Goldbach conjecture. Usually what ended up is either he fails to reinvent the wheel, or reinvent the exact same wheel, which has no value. The phrase certainly does not apply to professionals.
- dwattttt 1y ago
  Even then, you know what's a good way to learn about how the current system works etc, maybe even the best way? I've got many failed projects behind me, and 0 regrets.
bmitc 1y ago
Ruff is actually a good example of the danger of rewrites. They rewrote tools but not all of the parts of the tools.
zzzeek 1y ago
ruff does not support custom plugins so is useless to me

eviks 1y ago

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

socalgal2 1y ago
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)
- the8472 1y ago
  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.
- jerpint 1y ago
  From just my observations they basically parallelized the install sequence instead of having it be sequential (among many other optimizations most likely)
- ekidd 1y ago
  I've translated code from Ruby to Python, and other code from Rust to Python. Rust's speed advantages typically come from one of a few places: 1. Fast start-up times, thanks to pre-compiled native binaries. 2. Large amounts of CPU-level concurrency with many fewer bugs. I'm willing to do ridiculous threading tricks in Rust I wouldn't dare try in C++. 3. Much lower levels of malloc/free in Rust compared to some high-level languages, especially if you're willing to work a little for it. Calling malloc in a multithreaded system is basically like watching the Millennium Falcon's hyperdrive fail. Also, Rust encourages abusing the stack to a ridiculous degree, which further reduces allocation. It's hard to "invisibly" call malloc in Rust, even compared to a language like C++. 4. For better or worse, Rust exposes a lot of the machinery behind memory layout and passing references. This means there's a permanent "Rust tax" where you ask yourself "Do I pass this by value or reference? Who owns this, and who just borrows is?" But the payoff for that work is good memory locality. So if you put in a modest amount of effort, it's fairly easy to make Rust run surprisingly fast. It's not an absolute guarantee, and there are couple of traps for the unwary (like accidentally forgetting to buffer I/O, or benchmarking debug binaries).
- physicsguy 1y ago
  The package resolution is a big part of it, it's effectively a constraint solver. I.e. if package A requires package B constrained between version 1.0 < X <= 2.X and Package B requires package C between... and so on and so on. Conda rewrote their package resolver for similar reasons
- globular-toast 1y ago
  There is a talk about it from one of the authors here: https://www.youtube.com/watch?v=gSKTfG1GXYQ https://www.youtube.com/watch?v=gSKTfG1GXYQ tl;dw Rust, a fast SAT solver, micro-optimisation of key components, caching, and hardlinks/CoW.
- captnswing 1y ago
  Extremely interesting presentation from Charlie Marsh about all the optimizations https://youtu.be/gSKTfG1GXYQ?si=CTc2EwQptMmKxBwG https://youtu.be/gSKTfG1GXYQ?si=CTc2EwQptMmKxBwG
  - socalgal2 1y ago
    Thanks. So from the video the biggest wins were 1. they way get the metadata for a package. packages are in zip files. zip files have their TOC at the end. So, instead of downloading the entire zip they just get the end of the file, read the TOC, then from that download just the metadata part I've written that code before for my own projects. 2. They cache the results of packages unzipped and then link into your environment This means there's no files being copied on the 2nd install. Just links. Both of those are huge time wins that would be possible in any language. 3. They store their metadata as a memory dump So, on loading there is nothing to parse. Admittedly this is hard (impossible?) in many languages. Certainly not possible in Python and JavaScript. You could load binary data but it won't be useful without copying it into native numbers/strings/ints/floats/doubles etc... I've done this in game engines to reduce load times in C/C++ and to save memory. It'd be interesting to write some benchmarks for the first 2. The 3rd is a win but I suspect the first 2 are 95% of the speedup.
- jerf 1y ago
  It became a bit of a meme, especially in the web development space, that all programs are always waiting on external resources like networks, databases, disks, etc., and so scripting languages being slower than other languages doesn't matter and they'll always be as fast as non-scripting languages. Even on a single core, this turns out to be simply false. It isn't that hard to either A: be doing enough actual computation that faster languages are in fact perceptibly faster, even, yes, in a web page handler or other such supposedly-blocked computation or B: without realizing it, have stacked up so many expensive abstractions on top of each other in your scripting language that you're multiplying the off-the-top 40x-ish slower with another set of multiplicative penalties that can take you into effectively arbitrarily-slower computations. If you're never profiled a mature scripting language program, it's worth your time. Especially if nobody on your team has ever profiled it before. It can be an eye-opener. Then it turns out that for historical path reasons, dynamic scripting languages are also really bad at multithreading and using multiple cores, and if you can write a program that can leverage that you can just blow away the dynamic scripting languages. It's not even hard... it pretty much just happens. (I say historical path reasons because I don't think an inability to multithread is intrinsic to the dynamic scripting languages. It's just they all came out in an era when they could assume single core, it got ingrained into them for a couple of decades, and the reality is, it's never going to come fully out. I think someone could build a new dynamic language that threaded properly from the beginning, though.) You really can see big gains just taking a dynamic scripting language program and turning it into a compiled language with no major changes to the algorithms. The 40x-ish penalty off the top is often in practice an underestimate, because that number is generally from highly optimized benchmarks in which the dynamic language implementation is highly tuned to avoid expensive operations; real code that takes advantage of all the conveniences and indirection and such can have even larger gaps. This is not to say that dynamic scripting languages are bad. Performance is not the only thing that matters. They are quite obviously fast enough for a wide variety of tasks, by the strongest possible proof of that statement. That said, I think it is the case that there are a lot of programmers who have no idea how much performance they are losing in dynamic scripting languages, which can result in suboptimal engineering decisions. It is completely possible to replace a dynamic scripting language program with a compiled one and possibly see 100x+ performance improvements on very realistic code, before adding in multithreading. It is hard for that not to manifest in some sort of user experience improvement. My pitch here is not to give up dynamic scripting languages, but to have a more realistic view of the programming language landscape as a whole.
doug_durham 1y ago
A big part of the "magic" is that there is a team of paid professionals maintaining and improving it. That's more important than it being written in Rust. If uv were forked it would devolve to the level of pip over time.

0cf8612b2e1e 1y ago

The history of Python package management is clear that everyone thinks they can do a better job than the status quo.

psunavy03 1y ago
In this case, they were right.
- dwattttt 1y ago
  I would say in many cases they were right; the history of Python package management is littered with winners as well as losers.
henry700 1y ago
Of course they do, this tends to happen when the history is it being hot flaming garbage.
nickelpro 1y ago
uv is purely a performance improvement, it changes nothing about the mechanics of Python environment management or packaging. The improvements came from lots of work from the entire python build system ecosystem and consensus building.
- 0cf8612b2e1e 1y ago
  Disagree in that uv makes switching out the underlying interpreter so straightforward. Becomes trivial to swap from say 3.11 to 3.12. The pybi idea. Sure, other tools could handle the situation, but being baked into the tooling makes it much easier to bootstrap different configurations.
  - nickelpro 1y ago
    Yes, it's faster and better than pyenv, but the mechanism it's using (virtual environments) is not a uv invention. uv does the Python ecosystem better than any other tool, but it's still the standard Python ecosystem as defined in the relevant PEPs.

jjtheblunt 1y ago

> an order of magnitude better off topic, but i wonder why that phrase gets used rather than 10x which is much shorter.

Scene_Cast2 1y ago
10x is too precise.
fkyoureadthedoc 1y ago
- sounds cooler - 10x is a meme - what if it's 12x better
refulgentis 1y ago
"10x" has been cheapened / heard enough / de facto, is a more general statement than a literal interpretation would indicate. (i.e. 10x engineer. Don't hear that much around these parts these days) Order of magnitude faces less of that baggage, until it does :)
- psunavy03 1y ago
  Would you say it faces . . . orders of magnitude less baggage?
bxparks 1y ago
I think of "an order of magnitude" as a log scale. It means somewhere between 3.16X and 31.6X.
- jjtheblunt 1y ago
  yeah that's what i meant with 10x, like it's +1 on the exponent, if base is 10. but i'm guessing what others are thinking, hence the question.
  - bxparks 1y ago
    The problem is that 10x appears to be a linear scale. It could mean 9.5x to 10.5x if it's supposed to have 2 significant digits. Or it could be 5x to 15x if it meant to have 1 significant digit.

mort96 1y ago

Honestly "don't reinvent the wheel" makes absolutely no sense as a saying. We're not still all using wooden discs as wheels, we have invented much better wheels since the neolithic. Why shouldn't we do the same with software?

aalimov_ 1y ago
I always took this saying as meaning that we don’t re-invent the concept of the wheel. For example the Boring company and Tesla hoping to reinvent the concept of the bus/train.. (iirc your car goes underground on some tracks and you get to bypass traffic and not worry about steering) A metal wheel is still just a wheel. A faster package manager is still just a package manager.
- haiku2077 1y ago
  That's not how I've ever seen it used in practice. People use it to mean "don't build a replacement for anything functional."
haiku2077 1y ago
Right, wheels are reinvented every few years. Compare tires of today to the ones 20 years ago and the technology and capability is very different, even though they look identical to a casual eye. My primary vehicle has off-road capable tires that offer as much grip as a road-only tire would have 20-25 years ago, thanks to technology allowing Michelin to reinvent what a dual-purpose tire can be!
- nightpool 1y ago
  > Compare tires of today to the ones 20 years ago and the technology and capability is very different, even though they look identical to a casual eye Can you share more about this? What has changed between tires of 2005 and 2025?
  - haiku2077 1y ago
    In short: Better materials and better computational models. https://www.caranddriver.com/features/a15078050/we-drive-the-worlds-most-busted-out-bmw-m3-feature/ https://www.caranddriver.com/features/a15078050/we-drive-the... > In the last decade, the spiciest street-legal tires have nearly surpassed the performance of a decade-old racing tire, and computer modeling is a big part of the reason (written about 8 years ago)

CrendKing 1y ago

I believe most of the time this phrase is said to an inexperienced artisan who has no idea how the current system works, what's the shortcoming of it, and how to improve upon it. Think of an undergraduate student who tries to solve the Goldbach conjecture. Usually what ended up is either he fails to reinvent the wheel, or reinvent the exact same wheel, which has no value. The phrase certainly does not apply to professionals.

dwattttt 1y ago
Even then, you know what's a good way to learn about how the current system works etc, maybe even the best way? I've got many failed projects behind me, and 0 regrets.

bmitc 1y ago

Ruff is actually a good example of the danger of rewrites. They rewrote tools but not all of the parts of the tools.

zzzeek 1y ago

ruff does not support custom plugins so is useless to me