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

311–320 of 468 posts

Re: How uv got so fast

#311

Post by formerly_proven »

lmm wrote: post #274
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…

Note that the advantages of Rust are not just execution speed: it's also a good language for expressing one's thoughts, and thus makes it easier to find and unlock the algorithmic speedups that really increase speed. But yeah. Python packaging has been dumb for decades and successive Python package managers recapitulated the same idiocies over and over. Anyone who had used both Python and a serious programming langua…

Cargo is not really good. The very much non-zero frequency of something with cargo not working for opaque reasons and then suddenly working again after "cargo clean", the "no, I invoke your binaries"-mentality (try running a benchmark without either ^C'ing out of bench to copy the binary name or parsing some internal JSON metadata) because "cargo build" is the only build system in the world which will never tell you what it built, the whole mess with features, default-features, no-default-features, of course bindgen/sys dependency conflicts, "I'll just use the wrong -L libpath for the bin crate but if I'm building tests I remember the ...64". cargo randomly deciding that it now has to rebuild everything or 50% of everything for reasons which are never to be known, builds being not reproducible, cargo just never cleaning garbage up and so on.

rustdoc has only slightly changed since the 2010s, it's still very hard to figure out generic/trait-oriented APIs, and it still only does API documentation in mostly the same basic 1:1 "list of items" style. Most projects end up with two totally disjointed sets of documentation, usually one somewhere on github pages and the rustdoc.

Rust is overall good language, don't get me wrong. But it and the ecosystem also has a ton of issues (and that's without even mentioning async), and most of these have been sticking around since basically 1.0.

(However, the rules around initialization are just stupid and unsafe is no good. Rust also tends to favor a very allocation-heavy style of writing code, because avoiding allocations tends to be possible but often annoying and difficult in unique-to-rust ways. For somewhat related reasons, trivial things are at times really hard in Rust for no discernible reason. As a concrete, simplistic but also real-world example, Vec::push is an incredibly pessimistic method, but if you want to get around it, you either have to initialize the whole Vec, which is a complete waste of cycles, or you yolo it with reserve+set_len, which is invalid Rust because you didn't properly use MaybeUninit for locations which are only ever written.)

Re: How uv got so fast

#312

Post by calenti »

optionalsquid wrote: post #185
xvector wrote: post #181

Earlier quoted context omitted.

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.

Office politics happen when the number of people at an office exceeds 2

Exceeds 1. Politics is the craft of influence. And, debatably, there's a politic even when population size=1, between your subconscious instinctive mind (eat the entire box of donuts) versus your conscious mind (don't spike your blood sugar).

Re: How uv got so fast

#313

Post by calenti »

zahlman wrote: post #231
Nextgrid wrote: post #187

Earlier quoted context omitted.

I think too many people happens because a company would rather hire 10 "market rate" people than 3 well-compensated ones. Headcount inflation dilutes responsibility and rewards, so even if one of the "market rate" guys does the best work possible they won't get rewarded proportionally... so if hard work isn't going to get them adequate comp, maybe politics will.

> a company would rather hire 10 "market rate" people than 3 well-compensated ones The former is probably easier . They don't have to justify or determine the salaries, and don't have to figure out who's worth the money, and don't have to figure out how to figure that out .

It also comes that the well-compensated people are probably that because they know how to advocate for their worth, which usually includes a list of things they will tolerate and a list they will not, whereas "market rate" is just happy to be there and more inclined to go along with, ya know, whatever.

Re: How uv got so fast

#314

Post by calenti »

ngcc_hk wrote: post #201
xvector wrote: post #181

Earlier quoted context omitted.

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.

It's a question of what you want to invest your time in. Everyone creates output, whether it's lines of code, a smoke screen to hide your social media time, or a set of ongoing conversations and perceptions than you have a use in the organization.

Re: How uv got so fast

#315

Post by tor825gl »

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,…

Why doesn't anaconda disprove this?

Re: How uv got so fast

#316

Post by weitendorf »

codeflo wrote: post #269
WD-42 wrote: post #214

Earlier quoted context omitted.

I don't know what you think "typical Foss projects" are but in my experience they are exactly like your systemd example: one person that does what they want and share it with the world. The rest of your argument doesn't really make any sense with that in mind.

That's no longer as true as it once was. I get the feeling that quite a few people would consider "benevolent dictator for life" an outdated model for open source communities. For better or worse, there's a lot of push to transition popular projects towards being led by committee. Results are mixed (literally: I see both successes and failures), but that doesn't seem to have any effect on the trend.

Only a very, very small fraction of open source projects get to the point where they legitimately need committees and working groups and maintainer politics/drama.

> quite a few people would consider "benevolent dictator for life" an outdated model for open source communities.

I think what most people dislike are rugpulls and when commercial interests override what contributors/users/maintainers are trying to get out of a project.

For example, we use forgejo at my company because it was not clear to us to what extent gitea would play nicely with us if we externalized a hosted version/deployment their open source software (which they somewhat recently formed a company around, and led to forgejo forking it under the GPL). I'm also not a fan of what minio did recently to that effect, and am skeptical but hopeful that seaweedfs is not going to do something similar.

We ourselves are building out a community around our static site generator https://github.com/accretional/statue as FOSS with commercial backing. The difference is that we're open and transparent about it from the beginning, and static site generators/component libraries are probably some of the least painful to fork or take issue with their direction, vs critical infrastructure like distributed systems' storage layer.

Bottom line is, BDFL works when 1. you aren't asking people to bet their business on you staying benevolent 2. you remain benevolent.

Re: How uv got so fast

#317

Post by mlrtime »

formerly_proven wrote: post #311
lmm wrote: post #274

Earlier quoted context omitted.

Note that the advantages of Rust are not just execution speed: it's also a good language for expressing one's thoughts, and thus makes it easier to find and unlock the algorithmic speedups that really increase speed. But yeah. Python packaging has been dumb for decades and successive Python package managers recapitulated the same idiocies over and over. Anyone who had used both Python and a serious programming langua…

Cargo is not really good. The very much non-zero frequency of something with cargo not working for opaque reasons and then suddenly working again after "cargo clean", the "no, I invoke your binaries"-mentality (try running a benchmark without either ^C'ing out of bench to copy the binary name or parsing some internal JSON metadata) because "cargo build" is the only build system in the world which will never tell you…

I have empathy for anyone who was required to use cargo on a nfs mounted fs. The number of files and random IO cargo uses makes any large project unusable.

I had to stop telling people to stop syncing their cargo env around nfs so many times, but sometimes they have no choice.

Re: How uv got so fast

#319

Post by nh2 »

vlovich123 wrote: post #230
crote wrote: post #220

Earlier quoted context omitted.

I don't think this makes a meaningful difference. The installation is a `curl | sh`, which downloads a tarball, which gets extracted to some directory in $PATH. It currently includes two executables, but having it contain two executables and a bunch of .so libraries would be a fairly trivial change. It only gets messy when you want it to make use of system-provided versions of the libraries, rather than simply vendor…

It gets mess not just in that way but also someone can have a weird LD_LIBRARY_PATH that starts to have problems. Statically linking drastically simplifies distribution and you’ve had to have distributed 0 software to end users to believe otherwise. The only platform this isn’t the case for is Apple because they natively supported app bundles. I don’t know if flat pack solves the distribution problem because I’ve not…

When you're shipping software, you have full control over LD_LIBRARY_PATH. Your entry point can be e.g. a shell script that sets it.

There is not so much difference between shipping a statically linked binary, and a dynamically linked binary that brings its own shared object files.

But if they are equivalent, static linking has the benefit of simplicity: Why create and ship N files that load each other in fancy ways, when you can do 1 that doesn't have this complexity?

Re: How uv got so fast

#320

Post by efilife »

DrawTR wrote: post #182
pecheny wrote: 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.

Editing the post to switch five "it's X not Y"s[1] is pretty disappointing. I wish people were more clear with their disclosure of LLM editing. [1]: https://github.com/andrew/nesbitt.io/commit/0664881a524feac4...

This is terrible. So disrespectful. It's baffling how someone can do this under their own name
Post reply on HN