The thing about boilerplate is that a good library or framework makes it optional, and / or automatically written.
I'd much rather django-admin startproject, npm init, or meteor create and get deterministic output than prompt an LLM and get who knows what.
In a mature web ecosystem, boilerplate is minimal. I worry now that we've given this task to LLMs, less development effort will go into startproject-esqe CLIs and good opinionated defaults.
Even with that, uv took some time at 100% CPU during dep resolution, which I imagine would've been much slower if in pure Python instead. Unless pip's backtracking is already in C.
I don't think it's true at all that "dropping features" makes uv fast. As an author of uv, I think that particular section of the article is way off base.
I don't find that to be a particularly strong argument that a Python package manager would be possible to be in the same ballpark of performance as a Rust one. There's quite a lot of it that either doesn't support the idea of Python being capable of the same level of performance or actively supports the opposite.
> PEP 658 went live on PyPI in May 2023. uv launched in February 2024. uv could be fast because the ecosystem finally had the infrastructure to support it. A tool like uv couldn’t have shipped in 2020. The standards weren’t there yet.
> Other ecosystems figured this out earlier. Cargo has had static metadata from the start. npm’s package.json is declarative. Python’s packaging standards finally bring it to parity.
Are there any tools written in Python since then that are anywhere as close to as fast as uv when operating on packages that use this newer format? I've yet to hear of one.
> No .egg support. Eggs were the pre-wheel binary format. pip still handles them; uv doesn’t even try. The format has been obsolete for over a decade.
It seems dubious that adding support for egg would prevent uv from being as fast on packages that don't use that format.
> Virtual environments required. pip lets you install into system Python by default. uv inverts this, refusing to touch system Python without explicit flags. This removes a whole category of permission checks and safety code.
Passing `--user` to `pip install` doesn't seem to make things noticeably faster in most cases.
> Parallel downloads. pip downloads packages one at a time. uv downloads many at once. Any language can do this.
Any language with a global interpreter lock certainly can't do that as effectively as a language without one.
> Python-free resolution. pip needs Python running to do anything, and invokes build backends as subprocesses to get metadata from legacy packages. uv parses TOML and wheel metadata natively, only spawning Python when it hits a setup.py-only package that has no other option.
This one is pretty self-explanatory.
The section at the end somewhat overlaps with the parts I called out, and I recognize that the author of that post is almost certainly more familiar with the specifics of uv and Python package management than me, but with a lack of concrete example of a Python package manager that's anywhere close to the level of performance of a Rust one, I can't help but feel like pip would probably be quite noticeably slower than a Rust alternative written with an identical feature set (whether that feature set is "what pip currently supports" or "the minimal set of features described here"). I could imagine it being something like, pip could maybe be optimized from being 50x slower than uv to only 5x, but if that's the case, I think "Rust isn't the main reason it's fast" is a bit of an oversimplification when the discussion is about comparisons to alternatives that are all written in Python.
It's certainly concise but I still remain unconvinced a human wrote it.
> It's a weapon disguised as helpfulness.
The source code is without a doubt AI (it's got a comment for the "<!-- Canonical URL -->"), so I guess one would have to assume they prepared the entire document beforehand, then fed it to Claude and instructed it to use that copy exactly.
...or they prompted "make me a site which tersely criticizes people who post AI slop on Slack, use the term slop grenade and style the site like nohello.net"
What model? Is it possible that you accidentally had the car in a power-on mode, but without the engine started? I've done that by accident in my Mitsubishi Outlander Sport. The symptoms are similar to what you describe. Actually, it was at a car wash -- attendant left the car power on and I thought the engine was running so tried to drive away. Got the car to move a bit (happened to be downhill) but it was super scary because the brake pedal was taking more and more force to push down and I could barely turn the steering wheel. Luckily I was smart enough to put it in park, check everything, and realize the engine wasn't running!
The brakes (n.b., spelling) and steering will feel increasingly stiff or "locked up" if your engine is off because the engine is not powering the vacuum system that powers the brake booster, and the steering will be extremely difficult to operate without the assistance of power steering.
Yep yep yep.. that explains it. Not the software fault as I original suspected (at least in the break-jamming case). What I "felt" like jammed was probably just that vacuum system not helping, but since it happened for the first time (with me), and so abruptly, it felt like the brakes were jammed.
But, the worrying, and a lot more scarier part is that this was not me accidentally leaving the car in accessory/power-on mode. The engine cut out while I was driving, which is itself a serious fault.
Regarding the steering wheel case, it still feels like electronic/software fault since the car was actually reversing on engine power. But, similar to the first case, most likely it was also not jammed, rather, i lost the power steering assist, and hence, it "felt" like jammed since it happened first time to me.
Im from India btw and the car in question is a 10+ year old Maruti Suzuki Swift Dzire.
---
Summary:
1. Break issue: vacuum assist lost due to engine shutting off (by itself) which "felt" like it "jammed" the breaks, but, most probably had just gotten super stiff instead.
2. Steering wheel: Still looks like a software/electronic fault, but, similar to the break case, it "felt" like jammed.. but, it had just gotten super stiff.
This all, however, is still so wrong. In either of the cases the fault was not mine, yet, I was put in a situation that could have been very serious.
So I researched a bit more on that break thingy... and just learned that this assist provides anywhere form 4x to 10x the assist. And without it, you would literally have to stand on the breaks with full body weight to have a similar effect. Wow!!
> Steer around obstacles while pressing brake hard
That seems like a good way to flip a car or truck.
Also runs counter to the advice that's given for surviving a sudden kangaroo on road at night incident .. for the past 60+ years.
eg:
Don’t swerve Most severe crashes involving an animal occur when the driver veers off the road, and hits something else instead. What’s more, the animal is just as likely to flee in the direction you’re steering.
Brake in a straight line The only thing worse than swerving, is swerving with locked up tyres. Keeping a straight-line trajectory while you hit the brakes will allow you to reduce speed quickly, then – if the animal still hasn’t moved and you’ve reached a safe speed – you can steer around.
I believe Barbing is saying to start braking and if you haven't stopped when you reach the obstacle, to keep the brake pressed hard while steering around it. That said, it's also important to manage wheel and/or brake lock-up if either happens.
Hehehe have a strong feeling I should not doubt you…
Ah, the entire headline was about coming soon, and it wasn’t at all. The car was going to be good and impressive thanks to future software updates from the company, but instead the lack of updates helped kill the car. (About right?)
How does this refute the comment you replied to? That comment was implying that Toyota Mirai et al are ill-advised, so seems like your "nope" should be a "yep."
I agree that it was not the best introduction when that would be seen from the perspective of "ill-advised" companies.
What I meant is that for rational companies there would be no reason to be happy about this development, because it does not solve any of the problems that prevent free hydrogen for being suitable for energy storage, especially in vehicles.
It is not the cost of generating hydrogen that makes uncompetitive the cars with hydrogen, but difficulties in its storage and transportation.
Most of the energy used by living beings also passes through splitting water into oxygen and hydrogen, but the hydrogen is never stored as such, but it is immediately used for synthesizing reduced carbon compounds, which are suitable for long storage and easy to carry by mobile beings. This has been proven in practice for billions of years as a suitable solution for long term energy storage.
When reading a document in a browser, I rely on the scrollbar to know things like: how long is it? Where am I in the document? How much of the document is on my screen right now?
This is critical for decisions like: "Should I read the whole thing?" and for building a mental map of the whole document.
I use the scrollbar to scroll between parts of the document if I need to flick back and forth quickly, say between the data and the interpretation, once I have that mental map and know where things roughly are.
Yeah, I could literally accept a non-clickable "scroll gauge" to be there all the time that will not be a click/drag target.
I can generate scroll events or use keys like HOME/PGUP/PGDN/END or even search forward/back via keyboard to jump around. And I also suffer when a slightly misplaced click causes a disorienting scroll instead of hitting some other interaction target near the window edge.
I'd much rather django-admin startproject, npm init, or meteor create and get deterministic output than prompt an LLM and get who knows what.
In a mature web ecosystem, boilerplate is minimal. I worry now that we've given this task to LLMs, less development effort will go into startproject-esqe CLIs and good opinionated defaults.
reply