I assume you mean EU directives and not Belgian law, and the thing is it's incredibly hard to pass an EU directive, it needs to originate in the Commission, then pass qualified majority in the Council then pass a vote in the Parliament. Nothing without a broad consensus can get anywhere near.
This is a ridiculous mindset. Llama 3.1 8B can do lots of things today and it'll still be able to do those things tomorrow.
If you baked one of these into a smart speaker that could call tools to control lights and play music, it will still be able to do that when Llama 4 or 5 or 6 comes out.
The point is that the GP's mindset is not very ridiculous if you value things by a price/utility ratio. Software and hardware advancements will lead to buyer's remorse faster than people get an ROI from local inference.
SW and HW advancements will bring this topic in the "good enough for vast majority" field, thus making GP point moot. You don't care if your LLM ASIC chip is not the latest one because it works for the use you purchased it for.
The highly dynamical nature of LLM itself will make part of the advantage of upgradable software not that interesting anymorw. [1]
[1] although security might be a big enough reason for upgrades to still be required
Was it a memory error or a data race? No. Rust only promises that those won't happen in safe Rust. What is embarrassing is trying to pin this on a specific programming language.
This has nothing to do with the language, and it's so irritating to see people falsely claiming it is. There is nothing whatsoever about Rust that meant the engineer had to write code to the effect of
if result.is_err() {
panic!()
}
That was a choice on the engineer's part, not something caused by the language. You could choose to write that code in any language. It might even be the right choice sometimes! But whether or not it was the right choice, the fact remains that responsibility stops with the programmer(s) who decided to have that code, not somehow with the language.
Agreed. A tool may allow the programmer to do something (with varying degrees of difficulty), but it’s always the programmer’s choice. Tools are inert by themselves. Only humans make choices.
But it wasn't the culprit, the code could have been in anything, or could have bubbled up errors to main, and it still would have failed with for an incorrect config.
I just don't think you have the dunk you think you do. The Rust crowd is very adamant about preventing /many/ bugs. I rarely hear it recommended as a silver bullet that never fails.
The only languages that eliminate logic bugs are formally verified ones, as the article points out. (And even then, your program is only as correct as your specification.) Ordinary Rust code is not formally verified. Anyone who claims Rust eliminates errors is either very naive or lying.
Type-safe Rust code is free from certain classes of errors. But that goes out the window the moment you parse input from the outside, because Rust types can enforce invariants (i.e. internal consistency), but input has no invariants. Rust doesn't ban you from crashing the program if you see input that violates an invariant. I don't know of any mainstream language that forbids crashing the program. (Maybe something like Ada? Not sure.)
I don't understand why you bemoan that Rust hasn't solved this problem, because it seems nigh unsolvable.
As someone who's been working heavily in Rust for the last year, I have to agree with you, here.
Look, there's a lot of folks who gripe about Rust; I used to be one of them. It's like someone took C-lang and pushed it to hard mode, but the core point keeps getting lost in these conversations: Rust never claimed to solve logic bugs, and nobody serious argues otherwise. What it does is remove an entire universe of memory-unsafety pitfalls that have historically caused catastrophic outages and security incidents.
The Cloudflare issue wasn’t about memory corruption or type confusion. It was a straight logic flaw. Rust can’t save you from that any more than Ada, Go, or Haskell can. Once you accept arbitrary external input, the compiler can’t enforce the invariants for you. You need validation, you need constraints, you need a spec, and you need tests that actually reflect the real world.
The idea that "only formally verified languages eliminate logic bugs" is technically correct but practically irrelevant for the scale Cloudflare operates at. Fully verified stacks exist, like seL4, but they are extremely expensive and restrictive. Production engineering teams are not going to rewrite everything in Coq. So we operate in the real world, where Rust buys us memory safety, better concurrency guarantees, and stricter APIs, but the humans still have to get the logic right.
This is not a Rust failure. It is the nature of software. If the industry switched from Rust to OCaml, Haskell, Ada, or C#, the exact same logic bug could still have shipped. Expecting Rust to prevent it misunderstands what problems Rust is designed to eliminate.
Rust does not stop you from writing the wrong code. It stops you from writing code that explodes in ways you did not intend. This wasn't the fault of the language, it was the fault of the folks who screwed up. You don't blame the hammer when you smack your thumb instead of a nail - you should blame your piss poor aim.
Skyrim on day one came out with a game breaking bug in the main quest, and it crashed a lot too. Starfield's problem is that it's a very boring procgen hell.
They cut out a ton of content, they should have left most of it in. There's more problems beyond just procedural generation. All the companions hold the same views. Even the bounty hunting group feels incomplete.
reply