Not my experience. For example the "official" way of achieving the equivalent of sum types (the visitor pattern) is so verbose that idiomatic Java tends to use the equivalent of a "single table inheritance" style instead of proper domain modelling, which inevitably leads to all sorts of logic errors. Idiomatic Java uses "magic" AOP because the alternatives are too verbose, but this also inevitably causes logic errors (indeed in some ways it's worse than C where you'd do the equivalent thing with a preprocessor macro, which is at least a bit more visible in the code even if only due to conventions like UPPERCASE names). What kind of logic errors are seen in C that you would claim that idiomatic Java avoids?
> Rust doesn't prevent programs from having logic errors.
Like everything around Rust, this has been discussed ad nauseam.
Preventing memory safety bugs has a meaningful impact in reducing CVEs, even if it has no impact on logic bugs. (Which: I think you could argue the flexible and expressive type system helps with. But for the sake of this argument, let's say it provides no benefits.)
It isn't like rust is the only language with memory safety; plenty of high level languages don't let you fiddle with memory bits in a way that would be unsafe. The tradeoff is that they typically come with garbage collectors.
If the only concern is "can an LLM write code in this language without memory errors" then there's plenty of reasons to choose a language other than Rust.
But the author isn't saying we should program in any of these memory safe languages. The author is saying why don't we vibe code in C, or even assembly.
This thread moved the conversation away from the posted article quite a few messages ago.
First, Rust has lots of checks that C and assembly don't, and AI benefits from those checks. Then, a post about those checks are related to memory safety, not logic errors. Then, a post about whether that's a helpful comment. Finally, me pointing out that checks regarding types and memory errors aren't unique to Rust and there's tons of languages that could benefit.
Since you want to bring it back to the original article, here's a quote from the author:
Is C the ideal language for vibe coding? I think I could mount an argument for why it is not, but surely Rust is even less ideal. To say nothing of Haskell, or OCaml, or even Python. All of these languages, after all, are for people to read, and only incidentally for machines to execute.
It would seem that the author fundamentally misunderstand significant reasons for many of the languages he mentions to be the way that they are.
> Rust has lots of checks that C and assembly don't, and AI benefits from those checks.
Fil-C gets you close in the case of C, but we can ignore it because, of course, F* has significantly more checks than Rust, and AI benefits from those checks. Choosing Rust would be as ridiculous as choosing C if that was your motivation.
But if you don't find the need for those checks in order to consider Rust, why not C or even assembly instead?
Well, that's what the checks are for: So that hallucinations are caught by said checks and can be fed back into the LLM to ruminate on.
If you don't find importance in those checks, you wouldn't choose Fil-C anyway. But, of course, it remains that if do find those checks to be important, you're going to use a serious programming language like F* anyway.
There is really no place for Fil-C, Rust, etc. They are in this odd place where they have too many checks to matter when you don't care about checks, but not enough checks when you do care about checks. Well, at least you could make a case for Fil-C if you are inheriting an existing C codebase and need to start concerning yourself with checks in that codebase which previously didn't have concern for them. Then maybe a half-assed solution is better than nothing. But Rust serves no purpose whatsoever.
The trade-off is intended to make it easier for people to write software. Garbage collected languages make it easier for people to write memory safe code at the expense of performance, significantly greater memory usage, and heavy dependencies/runtimes.
These trade-offs are wholly unnecessary if the LLM writes the software in Rust, assuming that in principle the LLM is able to do so.
Yeah and I would say they're probably a better choice for vibe coding than C!
But most of them don't have a nice strong type system like Rust. I have vibe coded some OCaml and that seems to work pretty well but I wouldn't want to use OCaml for other reasons.
Can these claims back themselves up with a study showing that over a large population size with sufficient variety, sourced from a collection of diverse environments, LLM output across a period of time is more reliably correct and without issue when outputting Rust? Otherwise this is nothing but unempirical conjecture.
Ah the classic "show me ironclad evidence of this impossible-to-prove-but-quite-clear thing or else you must be wrong!"
Although we did recently get pretty good evidence of those claims for humans and it would be very surprising if the situation were completely reversed for LLMs (i.e. humans write Rust more reliably but LLMs write C more reliably).
Actually it's the classic "inductive reasoning has to meet a set of strict criteria to be sound." Criteria which this does not meet. Extrapolation from a sample size of one? In a context without any LLM involvement? That's not sound, the conclusion does not follow. The point being, why bother making a statistical generalization? Rust's safety is formally known, deduction over concrete postulates was appropriate.
> it would be very surprising if the situation were completely reversed for LLMs
Lifetimes must be well-defined in safe Rust, which requires a deep degree of formal reasoning. The kind of complex problem analysis where it is known that LLMs produce worse results in than humans. Specifically in the context of security vulnerabilities, LLMs produce marginally less but significantly more severe issues in memory safe languages[1]. Still though, we might say LLMs will produce safer code with safe Rust, on the basis that 100,000 vibe coded lines will probably never compile.
I never claimed to be doing a formal proof. If someone said "traffic was bad this morning" would you say "have you done a scientific study on the average journey times across the year and for different locations to know that it was actually bad"?
> LLMs produce worse results in than humans
We aren't talking about whether LLMs are better than humans.
Also we're obviously talking about Rust code that compiles. Code that doesn't compile is 100% secure!
I didn't claim that you were doing formal proofs. You can still make bad rhetoric, formal or not. You can say "The sky is blue, therefore C is a memory safe language" and that's trivially inferred to be faulty reasoning. For many people bad deduction is easier to pick up on than bad induction, but they're both rhetorically catastrophic. You are making a similarly unsound conclusion to the ridiculous example above, its not a valid statistical generalization. Formal or not the rhetoric is faulty.
> would you say "have you done a scientific study on the average journey times across the year and for different locations to know that it was actually bad"?
In response to a similarly suspiciously faulty inductive claim? Yeah, absolutely.
> We aren't talking about whether LLMs are better than humans.
The point I'm making here is specifically in response to the idea that it would "be surprising" if LLMs produced substantially worse code in Rust than they did in C. The paper I posted is merely a touch point to demonstrate substantial deviation in results in an adjacent context. Rust has lower surface area to make certain classes of vulns under certain conditions, but that's not isomorphic with the kind of behavior LLMs exhibit. We don't have:
- Guarantees LLMs will restrict themselves to operating in safe Rust
- Guarantees these specific vulnerabilities are statistically significant in comparative LLM output
- The vulnerability severity will be lower in Rust
Where I think you might be misunderstanding me is that this isn't a statement of empirical epistemological negativism. I'm underlining that this context is way too complex to be attempting prediction. I think it should be studied, and I hope that it's the case LLMs can write good, high quality safe Rust reliably. But specifically advocating for it on gut assumptions? No. We are advocating for safety here.
Because of how chaotic this context is, we can't reasonably assume anything here without explicit data to back it up. It's no better than trying to predict the weather based on your gut. Hence, why I asked for specific data to back the claim up. Even safe Rust isn't safe from security vulnerabilities stemming from architectural inadequacies and panics. It very well may be the case that in reasonably comparable contexts, LLMs produce security vulnerabilities in real Rust codebases at the same rate they create similar vulnerabilities in C. It might also be the case that they produce low severity issues in C at a similar statistical rate as high severity issues in Rust. For instance, buffer overflows manifesting in 30% of sample C codebase resulting in unexploitable segfaults, vs architectural deficiencies in a safe Rust codebase, manifesting in 30% of cases, that allow exfiltration of everything in your databases without RCE. Under these conditions, I don't think it's reasonable to say Rust is a better choice.
Again, it's not a critique in some epistemological negativist sense. It's a critique that you are underestimating how chaotic this context actually is, and the knock-on effects of that. Nothing should surprise you.
> Rust doesn't prevent programs from having logic errors.
Sure, but it prevents memory safety issues, which C doesn't. As for logic bugs, what does prevent them? That's a bigger question but I'd suggest it's:
1. The ability to model your problem in a way that can be "checked". This is usually done via type systems, and Rust has an arguably good type system for this.
2. Tests that allow you to model your problem in terms of assertions. Rust has decent testing tooling but it's not amazing, and I think this is actually a strike against Rust to a degree. That said, proptest, fuzzing, debug assertions, etc, are all present and available for Rust developers.
There are other options like using external modeling tools like TLA+ but those are decoupled from your language, all you can ever do is prove that your algorithm as specified is correct, not the code you wrote - type systems are a better tool to some degree in that way.
I think that if you were to ask an LLM to write very correct code then give two languages, one with a powerful, express type system and testing utilities, and one without those, then the LLM would be far more likely to produce buggy code in the system without those features.
Logic errors always stems from lack of understanding and inattention. The former is resolved by good communication and analytical skills. The other is just human nature, but we do have guardrails to help, like static analysis and tests. If used correctly.
There are static tools available for C as well. What you get from Rust mostly is that the check is part of the syntax of the language as well and escaping from it is very visible. You get safety, but you give up flexibility and speed.
You can't get a gutter ball if you put up the rails in a bowling lane. Rust's memory safety is the rails here.
You might get different "bad code" from AI, but if it can self-validate that some code it spits out has memory management issues at compile time, it helps the development. Same as with a human.
Modern medicine can't prevent or cure all diseases, so you might as well go back to drinking mercury then rubbing dog shit into your wounds.
Modern sewers sometimes back up, so might as well just releive yourself in a bucket and dump it into your sidewalk.
Modern food preservation doesn't prevent all spoilage so you might as well just go back to hoping that meat hasn't been sitting in the sun for too many days.
With a lot of competition you might have 20 great shows spread across 10 streamers. People will complain because they’d have to subscribe to 10 streamers to get everything.
Consolidation reduces the number of streamers, but reduces the competition too. The number of great shows will go down faster than than the number of streamers too.
The endpoint would be one streamer, with maybe 0-1 great shows. The vast majority of content will be low risk and cheap to produce.
With one big streamer it will be easy to manage your subscription, but the price will still be at least as high as subscribing to half a dozen small streamers, and the shows will be worse.
(Hope you like repetitive, formulaic shows, which, at best, are a rehash last year’s mildly entertaining show. That’s what you can look forward to.)
> but quite weak evidence for the vaccine being efficacious
That’s directly contradicted by the results of the study. E.g.,
“Vaccinated individuals had a 74% lower risk of death from severe COVID-19 (weighted hazard ratio [wHR], 0.26 [95% CI, 0.22-0.30]) and a 25% lower risk of all-cause mortality (wHR, 0.75 [95% CI, 0.75-0.76])…”
It’s pretty clear a lot of unvaccinated people who died of covid would be alive today had they gotten vaccinated.
(I would point out the current yearly vaccine they are putting out is potentially a different story since covid is changing and so is the vaccine. I’d talk to my dr about whether to get that or not.)
> Makes me wonder how much to the mass strife and confusion of the internet is simply down to people not knowing what the words they use mean?
Or being intentionally misled about them. People who enjoy being awful in various ways have a vested interest in reframing the opposition as "political correctness" in order to make it easier to dismiss or ridicule. The vast majority of usage of the term "political correctness" is in dismissing or ridiculing it.
It has everything to do with political correctness. Honest, blunt language is now de-valued in favor of passive, sanitized, AI-slop language that no longer conveys important information. The revised post forgot to mention the critical point of the bloated, buggy Javascript framework because it would offend someone here.
Prefer a blunt, honest dick over a passive, polite liar anyday.
I think the author is trying to apply a preconceived cause on to the cloudflare outage, but there’s not a fit.
E.g., they should try to work through how their own suggested fix would actually ensure the problem couldn’t happen. I don’t believe it would… lack of nullable fields and normalization typically simplify relational logic, but hardly prevent logical errors. Formal verification can prove your code satisfies a certain formal specification, but doesn’t prove your specification solves your business problem (or makes sense at all, in fact).
Yes. It correlates strongly with problem solving abilities on most tasks, predicts health outcomes, educational outcomes, career outcomes and finances all pretty significantly.
I don't see the particularly useful/meaningful part here.
Who knows what you're referring to, but generally IQ tests measure general mental abilities on things society generally finds good. That's fine, but general education does the same in far more detail and comes with a robust achievement measurement (grades, and graduation/degrees).
IQ competes with other measures that exist anyway and comes up short.
Grades aren't necessarily an indicator on if a person comprehends the educational material. Someone can visibly under-perform on general tests, but when questioned in-person/made to do an exam still recite the educational material from the top of their head, apply it correctly and even take it in a new direction. Those are underachievers; they know what they can do, but for one reason or another, they simply refuse to show it (a pretty common cause tends to be just finding the general coursework to be demeaning or the teachers using the wrong education methods, so they don't put a lot of effort into it[0].) Give them coursework above their level, and they'll suddenly get acceptable/correct results.
IQ can be used somewhat reliably to identify if someone is an underachiever, or if they're legitimately struggling. That's what the tests are made and optimized for; they're designed to test how quickly a person can make the connection between two unrelated concepts. If they do it quick enough, they're probably underachieving compared to what they actually can do and it may be worth trying to give them more complicated material to see if they can actually handle it. (And conversely, if it turns out they're actually struggling, it may be worth dedicating more time to help them.)
That's the main use of it. Anything else you attach to IQ is a case of correlation not being causation, and anyone who thinks it's worth more than that is being silly. High/Low IQ correlates to very little besides a sort of general trend on how quickly you can recognize patterns (because of statistical anomaly rules, any score outside the 95th percentile is basically the same anyways and IQ scores are normalized every couple years; this is about as far as you can go with IQ - there's very little difference between 150/180/210 or whatever other high number you imagine).
The advice here is contradictory. It suggests you should build and own things your business depends on, wherever possible, but also that you should buy things that aren't a core value of your core business.
There would very typically be a large overlap here.
Probably very few companies should build and run their own CDN and internet scale firewall, for example. Doesn't have to be cloudflare, but there aren't any providers that will have zero outages (a homegrown one is likely to be orders of magnitude worse and more expensive).
Found while seeking Linux laptop emulation of USB OTG HID kb/mouse on USB-c cable to iPad/iPhone/Pixel, like a remote KVM.
Once KB/mouse emulation exists, it can be integrated with Linux window manager to treat a tablet/phone as external "display", e.g. move Linux mouse pointer to the right edge of laptop display, push to the right with a bit of physics delay, then activate kb/mouse emulation and send all keystrokes and mouse movements over USB-c cable to the external device.
This would avoid the travel weight cost of a dedicated keyboard for tablet or phone.
The US government can exert control over aspects of employee communications related to their job function.
The US government cannot require employees to express political views unrelated to their job function.
The US constitution places restrictions on the government that don’t necessarily apply to private sector employers (or that don’t apply in the same way).
If LLMs produce code riddled with bugs in one language it will do in other languages as well. Rust isn't going to save you.
reply