Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How uv got so fast

nesbitt.io

Post reply on HN
Print view View original

31–40 of 468 posts

Re: How uv got so fast

#31

Post by saidnooneever »

yjftsjthsd-h wrote: post #6
woodruffw wrote: post #3

Earlier quoted context omitted.

No, because Python itself will generate bytecode for packages once you actually import them. uv just defers that to first-import time, but the cost is amortized in any setting where imports are performed over multiple executions.

That sounds like yes? Instead of doing it once at install time, it's done once at first use. It's only once so it's not persistently slower, but that is a perf hit. My first cynical instinct is to say that this is uv making itself look better by deferring the costs to the application, but it's probably a good trade-off if any significant percentage of the files being compiled might not be used ever so the overall cos…

you are right. it depends on how often this first start is, if its bad or not..most usecases id guess (total guess, have limited exp with python projects professionally) its not an issue.

Re: How uv got so fast

#32

Post by skywhopper »

This is great to read because it validates my impression that Python packaging has always been a tremendous overengineered mess. Glad to see someone finally realized you just need a simple standard metadata file per package.

Re: How uv got so fast

#33

Post by looneysquash »

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?

Re: How uv got so fast

#34

Post by VerifiedReports »

aw1621107 wrote: post #29
aswegs8 wrote: 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

> uv seems to be a pet peeve of HN. Unless I've been seeing very different submissions than you, "pet peeve" seems like the exact opposite of what is actually the case?

Indeed; I don't think he knows what "peeve" means...

Re: How uv got so fast

#35

Post by hallvard »

hallvard wrote: post #30

Great post, but the blatant chatgpt-esque feel hits hard… Don’t get me wrong, I love astral! and the content, but…

Reading the other replies here makes it really obvious that this is some LLM’s writing. Maybe even all of it…

Re: How uv got so fast

#36

Post by VerifiedReports »

So... will uv make Python a viable cross-platform utility solution?

I was going to learn Python for just that (file-conversion utilities and the like), but everybody was so down on the messy ecosystem that I never bothered.

Re: How uv got so fast

#37

Post by aurumque »

ec109685 wrote: post #26

The article info is great, but why do people put up with LLM ticks and slop in their writing? These sentences add no value and treats the reader as stupid. > This is concurrency, not language magic. > This is filesystem ops, not language-dependent. Duh, you literally told me that the previous sentence and 50 million other times.

This kind of writing goes deeper than LLM's, and reflects a decline in both reading ability, patience, and attention. Without passing judgement, there are just more people now who benefit from repetition and summarization embedded directly in the article. The reader isn't 'stupid', just burdened.

Re: How uv got so fast

#38

Post by Levitating »

yjftsjthsd-h wrote: post #8
woodruffw wrote: post #5

I think this post does a really good job of covering how multi-pronged performance is: it certainly doesn't hurt uv to be written in Rust, but it benefits immensely from a decade of thoughtful standardization efforts in Python that lifted the ecosystem away from needing `setup.py` on the hot path for most packages.

I think a lot of rust rewrites have this benefit; if you start with hindsight you can do better more easily. Of course, rust is also often beneficial for its own sake, so it's a one-two punch:)

> I think a lot of rust rewrites have this benefit

I think Rust itself has this benefit

Re: How uv got so fast

#39

Post by dddgghhbbfblk »

woodruffw wrote: post #10
yjftsjthsd-h wrote: post #6

Earlier quoted context omitted.

That sounds like yes? Instead of doing it once at install time, it's done once at first use. It's only once so it's not persistently slower, but that is a perf hit. My first cynical instinct is to say that this is uv making itself look better by deferring the costs to the application, but it's probably a good trade-off if any significant percentage of the files being compiled might not be used ever so the overall cos…

> 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?
Post reply on HN