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

421–430 of 468 posts

Re: How uv got so fast

#421

Post by baby_souffle »

rldjbpin wrote: post #420
baby_souffle wrote: post #157

Earlier quoted context omitted.

I largely agree but don't want to entirely discount the effect that using a compiled language had. At least in my limited experience, the selling point with the most traction is that you don't already need a working python install to get UV. And once you have UV, you can just go! If I had a dollar for every time I've helped somebody untangle the mess of python environment libraries created by an undocumented mix of p…

> If I had a dollar for every time I've helped somebody untangle the mess of python environment libraries created by an undocumented mix of python delivered through the distributions package management versus native pip versus manually installed... macos and linux usually come with a python installation out of the box. windows should be following suite but regardless, using uv vs venv is not that different for most u…

> macos and linux usually come with a python installation out of the box

Yep. But it's either old or broken or both. Using a tool not dependent on the python ecosystem to manage the python ecosystem is the trick here that makes it so reliable and invulnerable to issues that characterize python / dependency hell.

Re: How uv got so fast

#422

Post by CamouflagedKiwi »

zahlman wrote: post #392
CamouflagedKiwi wrote: post #361

Earlier quoted context omitted.

> You'd think PyPy would be more popular, then. PyPy doesn't do anything to help startup time. In fact, it's typically a bit slower to start up than CPython. You reap the speed benefits from PyPy once it's been running for a little while and it can JIT compile the hot bits of code.

> PyPy doesn't do anything to help startup time. In fact, it's typically a bit slower to start up than CPython. Considerably slower on my machine. Yes, that was my point. If the community doesn't care about startup time, you'd expect more adoption of an implementation that sacrifices that startup time for later performance.

Oh I see, sorry. I misread it as meaning that you'd expect the community to use PyPy more to alleviate the startup time issue.

Re: How uv got so fast

#423

Post by zahlman »

jacquesm wrote: post #415
zahlman wrote: post #395

Earlier quoted context omitted.

> Scenarios like that occur daily. I do quite a bit of software development and whenever I come across something that really needs python I mentally prepare for a day of battle with the various (all subtly broken) package managers, dependency hell and circular nonsense to the point that I am also ready to give up on it after a day of trying. Please name a set of common packages that causes this problem reliably.

You're getting a bit boring, and are not arguing in good faith. "Reliably"... as per your definition I guess. You have now made 60(!!!) comments in this thread questioning everything and everybody without ever once accepting that other people's experiences do not necessarily have to match your own. If you did some reading rather than just writing you'd have seen that I gave a very specific example right in this threa…

The large majority of my comments ITT are not in fact "questioning everything and everybody". I checked your comment history and couldn't find other comments from you ITT, and the post I responded to does not contain anything like a "very specific example". Your accusations are entirely unfounded, and frankly inflammatory.

Re: How uv got so fast

#424

Post by wging »

bastawhiz wrote: post #372
wging wrote: post #93

Earlier quoted context omitted.

I think the article is being careful not to say uv ignores _all_ upper bound checks, but specifically 4.0 upper bound checks. If a package says it requires python < 3.0, that's still super relevant, and I'd hope for uv to still notice and prevent you from trying to import code that won't work on python 3. Not sure what it actually does.

uv doesn't support <3.0 (I think the minimum is 3.8?) so it would be difficult for that to be relevant. But for pip, obviously yes.

uv supports PyPI, which still has packages that are Python-2-only. So even if you're running python 3.8, it seems possible to try to declare a dependency on some <3.0 code from PyPI. That means it's an error they should detect.

Re: How uv got so fast

#425

Post by rldjbpin »

baby_souffle wrote: post #421
rldjbpin wrote: post #420

Earlier quoted context omitted.

> If I had a dollar for every time I've helped somebody untangle the mess of python environment libraries created by an undocumented mix of python delivered through the distributions package management versus native pip versus manually installed... macos and linux usually come with a python installation out of the box. windows should be following suite but regardless, using uv vs venv is not that different for most u…

> macos and linux usually come with a python installation out of the box Yep. But it's either old or broken or both. Using a tool not dependent on the python ecosystem to manage the python ecosystem is the trick here that makes it so reliable and invulnerable to issues that characterize python / dependency hell.

imho the dependency hell is a product of the dependencies themselves (a la node), especially the lack of version fixing in majority of projects.

conda already had the independence from python distribution, but it still had its own set of problems with overlap with pip (see mamba).

i personally use uv for projects at work, but for smaller projects, `requirements.txt` feel more readable than the `toml` and `uv.lock`. in the spirit of encouraging best practices, it is still probably simpler to do it with older tools. but larger projects definitely benefit, such as in building container images.

Re: How uv got so fast

#426

Post by KPGv2 »

zahlman wrote: post #135
KPGv2 wrote: post #115

Earlier quoted context omitted.

> I genuinely can't understand why you suppose that has to do with the implementation language at all. Languages that attract novice programmers (JS is an obvious one; PHP was one 20 years ago) have a higher noise to signal ratio than one that attracts intermediate and above programmers. If you grabbed an average Assembly programmer today, and an average JavaScript programmer today, who do you think is more careful a…

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.

[flagged]

Re: How uv got so fast

#427

Post by NewsaHackO »

stephendause wrote: post #404
NewsaHackO wrote: post #326

Earlier quoted context omitted.

I recsind my previous statement. Also, people have to stop putting everything on github.

Why? To me, hosting previous versions of an article in a public git repo adds transparency. Or perhaps you are talking about GitHub specifically?

That is correct for the collective as a whole, but in his instance, if this wasn't connect to a public github, it would have been substanially more difficult to prove he used a LLM.

Re: How uv got so fast

#428

Post by zahlman »

KPGv2 wrote: post #426
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.

[flagged]

> because it mistakenly treats a cause as having only one effect.

If A causes other things besides B, then knowing about those other caused things tells us nothing about whether C happened, because we already know it did. "no further information" is elided to things that are relevant to the statement being made. Please apply basic charity in interpreting ideas expressed in prose; LWers who want to express something precisely in logical or mathematical notation are certainly not afraid to do so.

> Less wrong is a bunch of people who think they understand Bayes better than they do.

The objection you point out is not relevant to demonstrating an understanding of Bayes' Law. It's just a semantic quibble.

Re: How uv got so fast

#429

Post by IgorPartola »

LtWorf wrote: post #382
habinero wrote: post #246

Earlier quoted context omitted.

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.

“The user can choose between starting their new policy on the first day of employment, the first day of the fiscal year, on a specific date, or some number of days after their prior policy expires. If they choose the first day of the fiscal year, the user must specify when their company’s fiscal year starts. If they choose a specific date they must choose a date that is after the first business day of the next month and no later than December 31st of the year that month belongs to. If the user specified some number of months after their current policy expired the user must provide a policy number and the number of days no less than 1 and no more than 365.”

Type validation can help with some of that but at some point it becomes way easier to just use imperative validation for something like this. It turns out that validating things that are easy is easy no matter what you do, and validating complex rules that were written by people who think imperatively is almost impossible to do declaratively in a maintainable way.

Post reply on HN