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

201–210 of 468 posts

Re: How uv got so fast

#201

Post by ngcc_hk »

xvector wrote: post #181
Nextgrid wrote: post #174

Earlier quoted context omitted.

Office politics happen when people determine they can get more money by engaging in politics instead of working. This is just an indicator people aren't being paid enough money (since people politicking around is detrimental to the company, it is better off paying them whatever it takes for them not to engage in such behavior). "You get what you pay for" applies yet again.

Hard disagree, most of my coworkers make well north of $1M and office politics is at an all time high. I believe office politics happens when there are simply too many people at a company or org.

I believe incompetence is the key. When someone cannot compete (or the office does not use yardstick that can be measurable) politics is the only way to get you up.

Switch to what Nobel prize to man instead of the woman who do the work … sometimes. Take the credit and get the promotion.

Re: How uv got so fast

#202

Post by insane_dreamer »

Nextgrid wrote: post #158
orliesaurus wrote: post #148

The most surprising part of uv's success to me isn't Rust at all, it's how much speed we "unlocked" just by finally treating Python packaging as a well-specified systems problem instead of a pile of historical accidents. If uv had been written in Go or even highly optimized CPython, but with the same design decisions (PEP 517/518/621/658 focus, HTTP range tricks, aggressive wheel-first strategy, ignoring obviously de…

It's not just greenfield-ness but the fact it's a commercial endeavor (even if the code is open-source). Building a commercial product means you pay money (or something they equally value) to people to do your bidding. You don't have to worry about politics, licensing, and all the usual FOSS-related drama. You pay them to set their opinions aside and build what you want, not what they want (and if that doesn't work,…

numpy would like a word

Re: How uv got so fast

#203

Post by kibwen »

zahlman wrote: post #66
epage wrote: post #24

> uv is fast because of what it doesn’t do, not because of what language it’s written in. The standards work of PEP 518, 517, 621, and 658 made fast package management possible. Dropping eggs, pip.conf, and permissive parsing made it achievable. Rust makes it a bit faster still. Isn't assigning out what all made things fast presumptive without benchmarks? Yes, I imagine a lot is gained by the work of those PEPs. I'm…

> Isn't assigning out what all made things fast presumptive without benchmarks? We also have the benchmark of "pip now vs. pip years ago". That has to be controlled for pip version and Python version, but the former hasn't seen a lot of changes that are relevant for most cases, as far as I can tell. > This also doesn't cover subtle things. Unsure if rkyv is being used to reduce the number of times that TOML is parsed…

> This is interesting in that I wouldn't expect that the typical resolution involves a particularly large quantity of TOML.

I don't know the details of Python's resolution algorithm, but for Cargo (which is where epage is coming from) a lockfile (which is encoded in TOML) can be somewhat large-ish, maybe pushing 100 kilobytes (to the point where I'm curious if epage has benchmarked to see if lockfile parsing is noticeable in the flamegraph).

Re: How uv got so fast

#206

Post by tyre »

mkoubaa wrote: post #161
Calavar wrote: post #80

Earlier quoted context omitted.

Paul Graham said the same thing about Python 20 years ago [1], and back then it was true. But once a programming langauge hits mainstream, this ceases to be a good filter. [1] https://paulgraham.com/pypar.html

He was right. Python programmers are still the most likely to prioritize getting things done quickly.

This is a pretty broad generalization!

The fastest iterating people engineers I’ve worked with often have a deep user focus rather than a language affiliation.

Re: How uv got so fast

#207

Post by forrestthewoods »

est wrote: post #200
forrestthewoods wrote: post #191

Earlier quoted context omitted.

Because a single docker image can run multiple programs that have mutually exclusive dependencies? Personally I never want program to ever touch global shared libraries ever. Yuck.

> a single docker image can run multiple programs You absolutely can. But it's not best practice. https://docs.docker.com/engine/containers/multi-service_cont...

God I hate docker so much. Running computers does not have to be so bloody complicated.

Re: How uv got so fast

#208

Post by MBCook »

morshu9001 wrote: post #188
edoceo wrote: post #153

Earlier quoted context omitted.

Consensus building and figuring out what was actually needed? Someone on this site said most tech problems are people problems - this feels like one. Greenfield mostly solves the problem because it's all new people.

I can't find the quote for this, but I remember Python maintainers wanted package installing and management to be separate things. uv did the opposite, and instead it's more like npm.

Do you remember the reason? I spend most of my time in the Java and JS ecosystems where one tool does both jobs.

In my mind they’re pretty heavily linked. But that may be based on not experiencing the opposite. At least not as far as I can remember.

Re: How uv got so fast

#209

Post by rgoulter »

mkoubaa wrote: post #161
Calavar wrote: post #80

Earlier quoted context omitted.

Paul Graham said the same thing about Python 20 years ago [1], and back then it was true. But once a programming langauge hits mainstream, this ceases to be a good filter. [1] https://paulgraham.com/pypar.html

He was right. Python programmers are still the most likely to prioritize getting things done quickly.

Eh.

I think the cultural context has changed.

In "python paradox", 'knows python' is an indication that the developer is interested in something technically interesting but otherwise impractical. Hence, it's a 'paradox' that you end up practically better off by selecting for something impractical.

These days, Python is surely a practical choice, so doesn't really resemble the "interested in something technically interesting but impractical".

Re: How uv got so fast

#210

Post by woodruffw »

dddgghhbbfblk wrote: post #128
woodruffw wrote: post #45

Earlier quoted context omitted.

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.)

Why would you want to slow down the more common thing instead of the less common thing? I'm not following that at all. That's why I asked if that's backwards.

Because you only slow down the more common thing once, and the less common thing is slower in absolute terms.
Post reply on HN