I just mean that the image input probably didn't affect the output at all. Could have just told it "I'm an amateur doing bulbs and batteries and it doesn't work" and it would give the #1 search result on forums for that which is "did you strip your wire."
I feel like I'm in the audience at a magician show, except most of the audience is breathlessly amazed and doesn't understand how easily tricked they are.
This really underscores how so much LLM "intelligence" is based off of people's experiences that they wrote about. It saddens me somewhat to see that it has basically all been captured by corporations now, and perhaps in a few years there will be little point in knowing things yourself simply because the LLMs will have gotten so good that there is no point to wasting the extra effort. Of course, this might lead to the atrophy of people's thinking muscles and a dumber and more subservient populace, but does anyone really care? Judging by the meteoric rise in the capabilities of LLMs over the past five years, is it really naïve to expect most knowledge work to be obsolete in the next ten?
The other stuff in this thread about decompiling firmware is a lot more interesting to me, though, seeing as it used to be a fairly demanding but rewarding task that has now been "solved" by Claude. It's a magic trick that is a lot harder to pull off than the other things in this thread.
Wow, I was always amazed by Andrew Tridgill's prolific contributions to ardupilot / mavlink when I did some minor work on those. Had no idea he was behind rsync and samba.
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.
I feel like, if an LLM can one-shot a say 500 LOC project from a single-line prompt, and doesn't require the user to make any choices, and the result is actually acceptable, then 499 of those LOC are definitionally "boilerplate". They have been demonstrated, by this process, to have no more design-information content than the prompt, except perhaps a few constants where effectively random / statistically likely values were good enough.
> In a mature web ecosystem, boilerplate is minimal.
I don't think I even have words for my level of disagreement here.
> I worry now that we've given this task to LLMs, less development effort will go into startproject-esqe CLIs and good opinionated defaults.
I certainly hope not. I feel like an LLM-powered project could very much benefit from having those kinds of pieces to work with.
I wonder this in general, what's the impetus for writing new frameworks and such? Are we already seeing a slow down in that space? HN front page certainly paints that picture.
You're better off plonking down an existing framework and getting all the structural boilerplate benefits the LLM can leverage.
LLMs are far better at frameworks they have a lot of training data for, if have been around for a while. They write more idiomatic, ecosystem friendly code. Does that still matter?
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.
Or... were you illustrating?
reply