Live data from Hacker News

How uv got so fast

nesbitt.io

41–50 of 468 posts

Re: How uv got so fast

#41
post #25

The content is nice and insightful! But God I wish people stopped using LLMs to 'improve' their prose... Ironically, some day we might employ LLMs to re-humanize texts that had been already massacred.

Interestingly I didn’t catch this, I liked it for not looking LLM written!

Re: How uv got so fast

#42
I remain baffled about these posts getting excited about uv’s speed. I’d like to see a real poll but I personally can’t imagine people listing speed as one of the their top ten concerns about python package managers. What are the common use cases where the delay due to package installation is at all material?

Edit to add: I use python daily

Re: How uv got so fast

#43
post #25

The content is nice and insightful! But God I wish people stopped using LLMs to 'improve' their prose... Ironically, some day we might employ LLMs to re-humanize texts that had been already massacred.

I have reached a point where any AI smell (of which this articles has many) makes me want to exit immediately. It feels tortuous to my reading sensibilities.

I blame fixed AI system prompts - they forcibly collapse all inputs into the same output space. Truly disappointing that OpenAI et all have no desire to change this before everything on the internet sounds the same forever.

Re: How uv got so fast

#44
post #25

The content is nice and insightful! But God I wish people stopped using LLMs to 'improve' their prose... Ironically, some day we might employ LLMs to re-humanize texts that had been already massacred.

Interestingly I didn’t catch this, I liked it for not looking LLM written!

“Why this matters” being the final section is a guaranteed give away, among innumerable others.

Re: How uv got so fast

#45

Earlier quoted context omitted.

> It's only once so it's not persistently slower, but that is a perf hit. Sure, but you pay that hit either way. Real-world performance is always usage based: the assumption that uv makes is that people run (i.e. import) packages more often than they install them, so amortizing at the point of the import machinery is better for the mean user. (This assumption is not universal, naturally!)

Ummm, your comment is backwards, right?

Which part? The assumption is that when you `$TOOL install $PACKAGE`, you run (i.e. import) `$PACKAGE` more than you re-install it. So there's no point in slowing down (relatively less common) installation events when you can pay the cost once on import.

(The key part being that 'less common' doesn't mean a non-trivial amount of time.)

Re: How uv got so fast

#46
post #42

I remain baffled about these posts getting excited about uv’s speed. I’d like to see a real poll but I personally can’t imagine people listing speed as one of the their top ten concerns about python package managers. What are the common use cases where the delay due to package installation is at all material? Edit to add: I use python daily

The biggest benefit is in CI environments and Docker images and the like where all packages can get reinstalled on every run.

Re: How uv got so fast

#47
post #42

I remain baffled about these posts getting excited about uv’s speed. I’d like to see a real poll but I personally can’t imagine people listing speed as one of the their top ten concerns about python package managers. What are the common use cases where the delay due to package installation is at all material? Edit to add: I use python daily

`poetry install` on my dayjob’s monolith took about 2 minutes, `uv sync` takes a few seconds. Getting 2 minutes back on every CI job adds up to a lot of time saved

Re: How uv got so fast

#48
post #22

uv seems to be a pet peeve of HN. I always thought pipenv was good but yeah, seems like I was being ignorant

I too use pipenv unless there's a reason not to. I hope people use whatever works best for them.

I feel that sometimes there's a desire on the part of those who use tool X that everyone should use tool X. For some types of technology (car seat belts, antibiotics...) that might be reasonable but otherwise it seems more like a desire for validation of the advocate's own choice.

Re: How uv got so fast

#49

I don't have any real disagreement with any of the details the author said. But still, I'm skeptical. If it is doable, the best way to prove it is to actually do it. If no one implements it, was it ever really doable? Even if there is no technical reason, perhaps there is a social one?

What are you talking about, this all exists

Re: How uv got so fast

#50

> No bytecode compilation by default. pip compiles .py files to .pyc during installation. uv skips this step, shaving time off every install. You can opt in if you want it. Are we losing out on performance of the actual installed thing, then? (I'm not 100% clear on .pyc files TBH; I'm guessing they speed up start time?)

If you have a dependency graph large enough for this to be relevant, it almost certainly includes a large number of files which are never actually imported. At worst the hit to startup time will be equal to the install time saved, and in most cases it'll be a lot smaller.
Post reply on HN