Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Several core problems with Rust

bykozy.me

Post reply on HN
Print view View original

221–230 of 341 posts

Re: Several core problems with Rust

#221

Post by jacquesm »

Mauneam wrote: post #151
rddbs wrote: post #144

Earlier quoted context omitted.

You get to choose between UB, a crash, or handling the error — same as most other languages. It’s not a reliability issue of the language if as an author of software you choose to crash in your failure handling cases. Claiming otherwise is either disingenuous or a failure to understand what actually happened.

No, it's not the "same as most other languages". C and C++ are actually the only mainstream languages that suffer from UB to this extent. The fact that, in practice, with Rust you get a crash instead of UB is 100% a reliability issue with the language. The crashes are inbuilt. And blaming the crash on the author, saying they "chose to crash", is exactly the same as blaming UB on the author of C code, saying they "cho…

If I could choose between UB and a crash I will chose the crash every time. The sooner the better, preferably in test. And that's where CF's real failure was.

Re: Several core problems with Rust

#222

Post by josephg »

lumost wrote: post #201
byko3y wrote: post #90

Earlier quoted context omitted.

>Eventually I rewrote my btree on top of Vecs. My node & leaf pointers are now array indices. The result? There is no longer any unsafe code. The code has become significantly simpler and it now runs ~10% faster than it did before, which is shocking to me. I guess bounds checks are cheaper than memory fragmentation on modern computers. Optimizations are very complex and potentially fragile in Rust, LLVM has to sort t…

>Do note that binary trees are mostly an obsolete legacy today — they are way too cache-unfriendly. I mean you could have written similar code in C++ using std::vector or std::dequeue and get the bounds checking too. This is simply not true, it's an ongoing thorn of mine that the Rust community seems to decide that anything which cannot be programmed in rust is obsolete legacy. This is a silly stance which is harming…

> it's an ongoing thorn of mine that the Rust community seems to decide that anything which cannot be programmed in rust is obsolete legacy.

Nobody is arguing that you can't program a binary tree or b-tree in rust.

I think its true that binary trees almost always perform worse than b-trees in programming in general. But that isn't a comment about rust. Its a comment about modern CPU memory & cache behavior.

Re: Several core problems with Rust

#223

Post by devnull3 »

There is a fundamental trade off between (1) Memory Safety (2) Zero cost abstraction/Performance (3) Ease of use

Rust attempts to solve this trifecta and that is where the complexity arises. If the problem at hand does not need async, then Rust has done commendable progress in dealing with the above trade-offs.

Async is in Rust can be hard because the problem it is trying to solve is hard.

All the above may be fine but when it comes to choosing the language in practice we need to think of trade-offs and guarantees that are suitable for problem at hand.

There is a reason why C++ reigns supreme in HFT and Gaming as memory safety is not super critical.

Disclaimer: I like Rust.

Re: Several core problems with Rust

#224

Post by jmaker »

deng wrote: post #200

> In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. Not a fact. Particularly in the embedded world, crashing is preferable to malfunctioning, as many embedded devices control things that might hurt people, directly or indirectly. > If a pacemaker stops — telling a victim “but the memory was not corrupted in the crash” is a weak co…

Yeah, the blog post is a very confused write-up. I saw lots of similar posts on LinkedIn recently, with quite a lot of likes and echo chamber comments. It’s just hilarious how a narrative emerges that reinforces biases due to ignorance. There must be a name for that sort of fallacy.

I love to write in Rust precisely because I can express failures more explicitly, it’s the transparency that wins here.

I’d frame the issue Cloudflare had rather in the PR review and QA corner, maybe as some AI complacency. But it’s not a problem with Rust.

Re: Several core problems with Rust

#225

Post by dev_l1x_be »

jmaker wrote: post #224
deng wrote: post #200

> In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. Not a fact. Particularly in the embedded world, crashing is preferable to malfunctioning, as many embedded devices control things that might hurt people, directly or indirectly. > If a pacemaker stops — telling a victim “but the memory was not corrupted in the crash” is a weak co…

Yeah, the blog post is a very confused write-up. I saw lots of similar posts on LinkedIn recently, with quite a lot of likes and echo chamber comments. It’s just hilarious how a narrative emerges that reinforces biases due to ignorance. There must be a name for that sort of fallacy. I love to write in Rust precisely because I can express failures more explicitly, it’s the transparency that wins here. I’d frame the is…

I love the ub Go forces you to have explicit error handling ones the most.

Re: Several core problems with Rust

#226

Post by tialaramex »

deng wrote: post #200

> In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. Not a fact. Particularly in the embedded world, crashing is preferable to malfunctioning, as many embedded devices control things that might hurt people, directly or indirectly. > If a pacemaker stops — telling a victim “but the memory was not corrupted in the crash” is a weak co…

Also stopping is a state which definitely might happen anyway and must be planned for. The pacemaker's wires can be dislodged or damaged, power sources fail, these things will stop the pacemaker regardless of how much you love the "just keep going" approach to software engineering. Which means medics have already thought about what they're going to do when this happens to a patient, and "The software failed" just goes on the same list as "10 year battery only last 8 years" in terms of undesirable but hardly impossible scenarios which constitute a medical emergency.

Re: Several core problems with Rust

#227

Post by phaylon »

deng wrote: post #200

> In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. Not a fact. Particularly in the embedded world, crashing is preferable to malfunctioning, as many embedded devices control things that might hurt people, directly or indirectly. > If a pacemaker stops — telling a victim “but the memory was not corrupted in the crash” is a weak co…

Something else I usually don't see: A system hitting a fail-safe is a lot easier to detect and handle from the outside than one that just enters an unknown invalid state.

Like, if the rule were "Always-Keep-Running" then hospital equipment power supplies wouldn't have circuit breakers that cut the power when something is wrong. But cutting power seems lot easier to detect for the backup power supply so it can fully take over.

Re: Several core problems with Rust

#228

Post by dontlaugh »

styluss wrote: post #192
vacuity wrote: post #160

Earlier quoted context omitted.

If any language would've had this bug, why is Rust being singled out? If the software was written in Go, would the bug get the same attention? No programming language should get flak for a bug that is not the fault of the programming language. This is Cloudflare's problem.

In Go, if one would ignore the error, it could result in a panic or the program would continue with some unexpected state. Go projects work on an honour system and either return Nils with errors or empty structs.

The same case in Go would’ve probably been a nil panic.

Re: Several core problems with Rust

#229

Post by imtringued »

deng wrote: post #200

> In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. Not a fact. Particularly in the embedded world, crashing is preferable to malfunctioning, as many embedded devices control things that might hurt people, directly or indirectly. > If a pacemaker stops — telling a victim “but the memory was not corrupted in the crash” is a weak co…

It's honestly mind boggling how people react to this. Rust turns unknown failures in C and C++ into known failures and suddenly the C/C++ people start caring about the failures, but attribute the failure to the new language, even though the same failures are secretly lurking in their C/C++ code bases. It's kind of like trying to silence a whistleblower.

>Please read the whole article. If the unwrap hadn't caused an exit, the process would've run out of memory, leading to a much less deterministic behavior which is much harder to diagnose and fix. I always prefer an early exit with a clear error instead of getting killed by the OOM reaper.

I am running into an undiagnosable CUDA "illegal memory access" problem in vLLM, a code base that is a mix of python and CUDA (via pytorch). At a certain load something appears to either overflow or corrupt the memory and vLLM restarts, which takes a minute, because it has to reload several dozens of GBs into memory and then rerun the CUDA graph optimizations.

The pacemaker argument is complete nonsense, because the pacemaker must keep working even if it crashes. You can forcibly induce crashes into the pacemaker during testing and engineer it to restart fast enough that it hits its timing deadline anyway. Meanwhile a silent memory corruption could cause the pacemaker to enter an unknown state where the code that runs the pacemaker algorithm is overwritten and it simply stops working altogether. Having a known failure state is a thousand times more preferrable to an unknown number of unknown failure states. Critical sections (mutexes) and unsafe code has to be panic free (or at least panic safe) in Rust, so the concept of writing code without panics isn't exactly a niche concept in Rust. For every panic based feature, there is usually a panic free equivalent.

Re: Several core problems with Rust

#230

Post by dontlaugh »

adastra22 wrote: post #214
josephg wrote: post #74

Earlier quoted context omitted.

> The cloudflare bug was not caused by rust Yeah. Rust’s Option::None as like null in C++. Unwrapping an option is like checking if something is null and crashing. This "crash from an unwrap" is just a null pointer exception / segfault in any other language. The same bug would be trivial to write in any other language, and with more or less the exact same result. Its just - weirdly news because it was rust code. What…

Rust makes it very, very easy to .unwrap() something, making panic-crashes the default error handling behavior for a lot of rust programmers. But it does this without, e.g., Erlang's reliability services that will auto-relaunch code that crashes. The end result is NOT a very good user experience. I say this as a Rust advocate and daily Rust programmer, btw.

It should probably have a different name.

But nil panics in Go are even easier, the compiler doesn’t even require you to opt in. I deal with that every day.

Post reply on HN