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

381–390 of 468 posts

Re: How uv got so fast

#381

Post by Der_Einzige »

yunohn wrote: post #43
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.

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.

Read our paper on de-slopping LLM outputs. It's far more than simply all having the same fixed AI system prompts. It's an overuse of post-training and contempt for pre-training.

https://arxiv.org/pdf/2510.15061

Re: How uv got so fast

#382

Post by LtWorf »

habinero wrote: post #246
IgorPartola wrote: post #186

Earlier quoted context omitted.

I rarely if ever encounter bugs that type checking would have fixed. Most common types of bugs for me are things like forgetting that two different code paths access a specific type of database record and when they do both need to do something special to keep data cohesive. Or things like concurrency. Or worst of all things like fragile subprocesses (ffmpeg does not like being controlled by a supervisor process). I t…

Same. I like the type hints -- they're nice reminders of what things are supposed to be -- but I've essentially ~never run into bugs caused by types, either. I've been coding professionally in Python for 10+ years at this point. It just doesn't come up in the web and devtools development worlds. Either you're dealing with user input, which is completely untrusted and has to be validated anyways, or you're passing aro…

You can validate user input with types using stuff like typedload (which i wrote) or similar runtime type checkers.

Re: How uv got so fast

#383

Post by quotemstr »

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.

More projects should push back against calls for "governance" and "steering committees" and such. As you noticed, they paralyze projects. It took JavaScript seven years to get a half-baked version of Python context managers, and Python itself has slowed down markedly.

The seemingly irresistible social pressure to committee-ize development is a paper tiger. It disappears if you stand your ground and state firmly "This is MY project".

Re: How uv got so fast

#384

Post by LtWorf »

tikhonj wrote: post #173
zahlman wrote: post #97

Earlier quoted context omitted.

> having relatively curious, meticulous, detail-oriented people on hand who were interested in solving hard problems.... Had we built those projects with JavaScript or Python I suspect the outcomes would have been worse for reasons apart from the language choice. I genuinely can't understand why you suppose that has to do with the implementation language at all.

Different programming languages come with different schools of thought about programming and different communities of practice around programming. If you take a group of people who are squarely in the enterprise Java school of thought and have them write Rust, the language won't make much of a difference. They will eventually be influenced by the broader Rust community and the Rust philosophy towards programming, but…

Since currently 0% of developers started with rust, it would be interesting to know from which language these developers are actually migrating.

Re: How uv got so fast

#385

Post by quotemstr »

Nextgrid wrote: post #174
eru wrote: post #170

Earlier quoted context omitted.

> 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, it just means you need to offer more money). Money is indeed a great lubricator. However, it's not black-and-white: office politics is a long standing term for a reason.

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.

Politics is just what happens when three or more humans get together. It's an inescapable part of human nature.

Re: How uv got so fast

#386

Post by LtWorf »

IgorPartola wrote: post #140
zahlman wrote: post #135

Earlier quoted context omitted.

Sure, but that kind of incompetence is already filtered out (in the https://www.lesswrong.com/w/screening-off-evidence sense) by the task of creating a package installer.

You would think so, yet here I am sitting with a node_modules full of crud placed there by npm, waiting for the next supply chain attack.

I don't think cargo is much better in that respect. It's what happens when instead of a decent standard library and a few well established frameworks you decide that every single little thing must be a separate project.

Re: How uv got so fast

#387

Post by mkoubaa »

vlovich123 wrote: post #374
nh2 wrote: post #319

Earlier quoted context omitted.

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

That’s precisely my point. It’s insanely weird to have a shell script to setup the path for an executable binary that can’t do it for itself. I guess you could go the RPATH route but boy have I only experienced pain from that.

RPATH is painless if you don't try to be clever

Re: How uv got so fast

#388

Post by eru »

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.

What industry is that, if I may ask?

Re: How uv got so fast

#389

Post by aaronblohowiak »

IgorPartola wrote: post #186
aaronblohowiak wrote: post #180

Earlier quoted context omitted.

If python's painpoints don't bother you enough (or you are already comfortable with all the workarounds,) then I'm not sure Rust will do much for you. What I like about Rust is ADTs, pattern matching, execution speed. The things that really give me confidence are error handling (right balance between "you can't accidentally ignore errors" of checked exceptions with easy escape hatches for when you want to YOLO,) and…

I rarely if ever encounter bugs that type checking would have fixed. Most common types of bugs for me are things like forgetting that two different code paths access a specific type of database record and when they do both need to do something special to keep data cohesive. Or things like concurrency. Or worst of all things like fragile subprocesses (ffmpeg does not like being controlled by a supervisor process). I t…

For me, ADT’s and pattern matching are about expressivity not type checking. Type checking really helps with refactoring quickly. If we’re measuring experience with years, I was a rubyist for over a decade and have written python for another 5 years after that, so I have some dynamic language bona fides.

Re: How uv got so fast

#390

Post by kibwen »

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…

Cargo is fantastic... for building Rust code. Once you start trying to also use it to build C code, you're moving outside of Cargo's wheelhouse, using features that Cargo only supports begrudgingly (like build scripts). Cargo is definitely not intended to be an end-all be-all build system for all languages; it's specialized for Rust, and that's what it's great at. For multi-language projects, you want some sort of simple tool to orchestrate the builds (e.g. `just` https://just.systems/man/en/ ) that internally calls out to Cargo (and whatever other build systems you have for whatever other languages you're using). The overall mistake is thinking that Cargo is a replacement for `make`, when it isn't nearly so general.
Post reply on HN