> But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.
That language may well be Rust itself, especially if they manage to figure out the "how to deprecate standard library features across language editions and allow reuse of their idiomatic syntax?" problem.
Totally true. Similarly I think a C revival is more likely than people might think because of Fil-C, improvements to the language standard, and maybe hardware improvements like CHERI. Eg, maybe there will be a new generation of Fil-C like compilers, maybe C will get a lot easier, and maybe that will cause C to displace Python as the preffered pedagogical "first language" (which would really be reprising it's role). Not because it's easier than Python but because it's easy enough and we start emphasizing low-level optimization more because AI is eating all of our compute. Stranger things have happened.
Fil-C is actually not very low-level efficient, Golang probably has better efficiency (being built from the ground up for lightweight concurrent GC) and a hypothetical support within Rust for "pluggable" GC heaps might be even more clearly preferable.
> It's a particularly bad one though because it always leads to UB, which means you can't say anything about what happens next.
This is also why memory safety is table-stakes when it comes to formal verification of the underlying program logic. You can't solve logic bugs (even where that's known to be feasible, such as for tightly self-contained, library-like features) without solving memory safety first.
> Rust has nothing new (even the lifetime stuff is copied) really.
Rust has nothing new by academic standards, and this is an explicit goal of the project. (And that's why it has yet to support e.g. Haskell-like higher-kinded types; or dependent types for compile-time programming: the interaction with its low-level featureset is very much an open question.) It's incredibly novel as a production language, of course.
"End of human-based value creation" is tantamount to post-scarcity. It "breaks" capitalism because it supposedly obviates the resource allocation problem that the free-market economy is the answer to. It's what Karl Marx actually pointed to as his utopian "fully realized communism". Most people would think of that as a pipe dream, but if you actually think it's viable, why wouldn't you want it?
Right now, their wiki page on device support [0] lists zero actual devices as "fully supported":
> These are the most supported devices, maintained by at least 2 people and have the functions you expect from the device running its normal OS, such as calling on a phone, working audio, and a functional UI.
> Besides QEMU devices, this is currently empty. The ports we had here earlier weren't as reliable as we would have liked. We plan to add new devices here with a higher standard.
The most recent smartphone in the Community section of that page is the Fairphone 4, released half a decade ago, in 2021. Pixel devices can trivially be bootloader unlocked, but that doesn't make the work that goes into supporting them much easier: the latest device in Testing is the 6a/6 Pro, from 2022, and its device page lists all the features but the most basic (touchscreen, flash, internal storage) as "Untested".
Obligatory reminder that today's so called "AGI" has trouble figuring out whether I should walk or drive to the car wash in order to get my dirty car washed. It has to think through the scenario step by step, whereas any human can instantly grok the right answer.
The idea/hope is that a video model would answer the car wash problem correctly. There are exactly the kinds of issues you have to solve to avoid teleporting objects around in a video, so whenever we manage more than a couple seconds of coherent video we will have something that understands the real world much better than text-based models. Then we "just" have to somehow make a combined model that has this kind of understanding and can write text and make tool calls
Yes, this is kind of like Tesla promising full self driving in 2016
I just don't know how to engage with these criticisms anymore. Do you not see how increasingly convoluted the "simple question LLMs can't answer" bar has gotten since 2022? Do the human beings you know not have occasional brain farts where they recommend dumb things that don't make much sense?
I should note for epistemic honesty that I expected I would be able to come up with an example of a mistake I made recently that was clearly equally dumb, and now I don't have a response to offer because I can't actually come up with that example.
That problem went viral weeks ago so is no longer a valid test. At the time it was consistently tripping up all the SOTA models at least 50% of the time (you also have to use a sample > 1 given huge variation from even the exact same wording for each attempt).
The large hosted model providers always "fix" these issues as best as they can after they become popular. It's a consistent pattern repeated many times now, benefitting from this exact scenario seemingly "debunking" it well after the fact. Often the original behavior can be replicated after finding sufficient distance of modified wording/numbers/etc from the original prompt.
For example, I just asked ChatGPT "The boat wash is 50 meters down the street. Should I drive, sail, or walk there to get my yacht detailed?" and it recommended walking. I'm sure with a tiny bit more effort, OpenAI could patch it to the point where it's a lot harder to confuse with this specific flavor of problem, but it doesn't alter the overall shape.
This question is obviously ambiguous. The context here on HN includes "questions LLMs are stupid about, I mention boat wash, clearly you should take the boat to the boat wash."
But this question posed to humans is plenty ambiguous because it doesn't specify whether you need to get to the boat or not, and whether or not the boat is at the wash already. ChatGPT Free Tier handles the ambiguity, note the finishing remark:
"If the boat wash is 50 meters down the street…
Drive? By the time you start the engine, you’re already there.
Sail? Unless there’s a canal running down your street, that’s going to be a very short and very awkward voyage.
Walk? You’ll be there in about 40 seconds.
The obvious winner is walk — unless this is a trick question and your yacht is currently parked in your living room.
If your yacht is already in the water and the wash is dock-accessible, then you’d idle it over. But if you’re just going there to arrange detailing, definitely walk."
You can make the argument that the boat variant is ambiguous (but a stretch), it's really not relevant since the point was revealing the underlying failure mode is unchanged, just concealed now.
The original car question is not ambiguous at all. And the specific responses to the car question weren't even concerned with ambiguity at all, the logic was borderline LLM psychosis in some examples like you'd see in GPT 3.5 but papered over by the well-spoken "intelligence" of a modern SOTA model.
I don't understand what occasional hiccups prove. The models can pass college acceptance tests in advanced educational topics better than 99% of the human population, and because they occasionally have a shortcoming, it means they're worse than humans somehow? Those edge cases are quickly going from 1% -> 0.01% too...
"any human can instantly grok the right answer."
When asking a human about general world knowledge, they don't have the generality to give good answers for 90% of it. Even very basic questions humans like this, humans will trip up on many many more than the frontier LLMs.
Even the rise of high-level languages did not lead to a "developer-less future". What it did was improve productivity and make software cheaper by orders of magnitude; but compiler vendors did not benefit all that much from the shift.
OTOH, out of order/speculative execution only amounts to information disclosure. And general purpose OS's (without mandatory access control or multilevel security, which are of mere academic interest) were never designed to protect against that.
A far greater problem is that until very recently, practical memory safety required the use of inefficient GC. Even a largely memory-safe language like Rust actually requires runtime memory protection unless stack depth requirements can be fully determined at compile time (which they generally can't, especially if separately-provided program modules are involved).
That language may well be Rust itself, especially if they manage to figure out the "how to deprecate standard library features across language editions and allow reuse of their idiomatic syntax?" problem.
reply