Live data from Hacker News

A year of uv: pros, cons, and should you migrate

bitecode.dev

61–70 of 401 posts

Re: A year of uv: pros, cons, and should you migrate

#61
post #36

Earlier quoted context omitted.

My use of python is somewhat recent. But the two languages that I have used a lot of - Java and JS - have interpreters that were heavily optimized over time. I wonder why that never happened with python and, instead, everyone continues to write their critical code in C/Rust. I am planning to shift some of my stuff to pypy (so a "fast" python exists, kind of). But some dependencies can be problematic, I have heard.

Neither Java nor JS encourages the use of native extensions to the same degree that Python does. So some of it is a fundamental difference in approach: Python has gotten very far by offloading hot paths into native code instead of optimizing the interpreter itself. (Recent positive developments in Python’s interpreted performance have subverted this informal tendency.)

> Neither Java nor JS encourages the use of native extensions to the same degree that Python does.

You already had billions of lines of Java and JS code that HAD to be sped up. So they had no alternative. If python had gone down the same route, speeding it up without caveats would have been that much easier.

Re: A year of uv: pros, cons, and should you migrate

#62
I have seen references to using uv for Python package management before and been thoroughly confused. I never realized it was not the same thing as the very nice asynchronous cross-platform library libuv (https://libuv.org/) and I could never figure out what that library had to do with Python package management (answer: nothing).

Maybe we need a Geographic Names Board to deconflict open source project names, or at least the ones that are only two or three characters long.

Re: A year of uv: pros, cons, and should you migrate

#63
post #36

Earlier quoted context omitted.

My use of python is somewhat recent. But the two languages that I have used a lot of - Java and JS - have interpreters that were heavily optimized over time. I wonder why that never happened with python and, instead, everyone continues to write their critical code in C/Rust. I am planning to shift some of my stuff to pypy (so a "fast" python exists, kind of). But some dependencies can be problematic, I have heard.

python just didn't have much momentum until relatively recently, despite it's age. There are efforts to speed it up going on now backed by Microsoft. For pypy it's in a weird spot as the things it does fast are the ones you'd usually just offload to a module implemented in C

As a long time Pythonista I was going to push back against your suggestion that Python didn't have much momentum until recently, but then I looked at the historic graph on https://www.tiobe.com/tiobe-index/ and yeah, Python's current huge rise in popularity didn't really get started until around 2018.

(TIOBE's methodology is a bit questionable though, as far as I can tell it's almost entirely based on how many search engine hits they get for "X programming". https://www.tiobe.com/tiobe-index/programminglanguages_defin...)

Re: A year of uv: pros, cons, and should you migrate

#64
post #21

Earlier quoted context omitted.

A lot of that is cuda blobs, right?

ROCm. About 40%. But there is duplication there as well. Two 16GB folders containing the exact same version.

Run rmlint on it, it will replace duplicate files with reflinks (if your fs supports them — xfs and btrfs do), or hardlinks if not.

Re: A year of uv: pros, cons, and should you migrate

#65
post #38

Earlier quoted context omitted.

Does uv have any plans for symlink/hardlink deduplication?

Not sure. The simplest solution is to store all files under a hashed name and sym/hardlink on a case to case basis. But some applications tend to behave weirdly with such files. Windows has its own implementation of symlinks and hardlinks. They simply call it something else. Perhaps portability could be an issue.

The article says it already hard links duplicates. But likely not able to help if you are using multiple versions of interpreter and lib.

Re: A year of uv: pros, cons, and should you migrate

#66
post #21

Earlier quoted context omitted.

ROCm. About 40%. But there is duplication there as well. Two 16GB folders containing the exact same version.

Run rmlint on it, it will replace duplicate files with reflinks (if your fs supports them — xfs and btrfs do), or hardlinks if not.

Thanks! Hearing about this for the first time. Never felt the need before.

Re: A year of uv: pros, cons, and should you migrate

#67

I've been mostly out of the python game for quite a while, but I never had that much issue with: pip install -r requirements.txt . Seems like a lot of people have tried their hand at various tooling, so there must be more to it than I am aware of.

This works if you only have one python project on your system, but most python developers need virtual environments to deal with various projects.

Re: A year of uv: pros, cons, and should you migrate

#68
post #61

Earlier quoted context omitted.

Neither Java nor JS encourages the use of native extensions to the same degree that Python does. So some of it is a fundamental difference in approach: Python has gotten very far by offloading hot paths into native code instead of optimizing the interpreter itself. (Recent positive developments in Python’s interpreted performance have subverted this informal tendency.)

> Neither Java nor JS encourages the use of native extensions to the same degree that Python does. You already had billions of lines of Java and JS code that HAD to be sped up. So they had no alternative. If python had gone down the same route, speeding it up without caveats would have been that much easier.

I don't think that's the reason. All three ecosystems had the same inflection point, and chose different solutions to it. Python's was especially "easy" since the C API was already widely used and there were no other particular constraints (WORA for Java, pervasive async for JS) that impeded it.

Re: A year of uv: pros, cons, and should you migrate

#69
post #51

uv is just so damn good. All else equal, I prefer julia to python, but uv makes the python experience so much nicer. I'd love it if julia copied uv and replaced the Pkg system with it.

What are some of the issues you've had with the Pkg system?
Post reply on HN