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

231–240 of 341 posts

Re: Several core problems with Rust

#231

Post by tialaramex »

josephg wrote: post #141
tialaramex wrote: post #130

Earlier quoted context omitted.

The Cloudflare bug was unwrapping a Result::Err not an Option::None. Both Option and Result can be unwrapped and - to some extent not coincidentally - both can also be subject to the Try operator (?) which is arguably more correct here than unwrap because this can fail and perhaps the caller will have some plan to recover. My list of peeves would be very different from yours. I would like to prohibit move of the dodg…

> Both Option and Result can be unwrapped and - to some extent not coincidentally - both can also be subject to the Try operator (?) which is arguably more correct here than unwrap because this can fail and perhaps the caller will have some plan to recover. I guess its equivalent to Go code like this: value, err := stuff() if err != nil { panic(err) } Or in C: int result = stuff(); assert(result >= 0); If someone wro…

I see what you mean for -> although personally I haven't missed it (I spent many years writing C) I don't write much pointer twiddling in Rust so I'm the wrong person to have an opinion.

However surely the aliasing is actually a problem and so MIRI is annoyed because what you wrote might be wrong? If we hang on to (*node).first_next() but somehow node changes, we're no longer talking about the same thing, it's exactly the aliasing problem.

I'd have to (which I have not) examine in detail how your code works to offer an opinion beyond speculation, but I think my instinct is sympathy for the "Don't write aliases" approach.

Re: Several core problems with Rust

#232

Post by imtringued »

EdwardDiego wrote: post #207
hypeatei wrote: post #68

> We actually had a recent Cloudflare outage caused by a crash on unwrap() function Oh boy, this is going to be the new thing for Rust haters isn't it? Yes, unwrapping an `Err` value causes a panic and that isn't surprising. Cloudflare had specific limits to prevent unbounded memory consumption, then a bad query returned a much larger dataset than expected which couldn't be allocated. There are two conclusions: 1) If…

Yet they spent ages trying to determine the actual cause of the failure, according to their postmortem, so I'm not sure what the advantage you're positing is?

Doing a naked unwrap() in a function that returns a Result is probably a crime against humanity. Like, this is the dumbest thing you could possibly do.

Re: Several core problems with Rust

#233

Post by dana321 »

hypeatei wrote: post #68

> We actually had a recent Cloudflare outage caused by a crash on unwrap() function Oh boy, this is going to be the new thing for Rust haters isn't it? Yes, unwrapping an `Err` value causes a panic and that isn't surprising. Cloudflare had specific limits to prevent unbounded memory consumption, then a bad query returned a much larger dataset than expected which couldn't be allocated. There are two conclusions: 1) If…

It was bad coding.

.unwrap() is not required to be used.

use:

if let Some(value)=something_to_unwrap{

}else{ // log an error and exit!! }

Re: Several core problems with Rust

#234

Post by imtringued »

blub wrote: post #195
hypeatei wrote: post #68

> We actually had a recent Cloudflare outage caused by a crash on unwrap() function Oh boy, this is going to be the new thing for Rust haters isn't it? Yes, unwrapping an `Err` value causes a panic and that isn't surprising. Cloudflare had specific limits to prevent unbounded memory consumption, then a bad query returned a much larger dataset than expected which couldn't be allocated. There are two conclusions: 1) If…

It has potential to be the new thing, since several details synergize to make this incident more powerful: 1. Previous claims that Rust code often just works after compiling. 2. Previous claims that low-level error-handling idioms like matching, using Result, etc improve code reliability. 3. Previous claims that using unwrap in example code is ok for brevity. Also, Rust developers would know not to use it in producti…

.unwrap() was a huge mistake. It should be banned from release builds outright. It's the equivalent of dereferencing a null pointer in C or the NullPointerException in Java. All .unwraps() should be replaced by .expect("uniquely identifying message") immediately and preferably the compiler checks that the expect messages are unique within a crate and issues a warning. Debug builds should by default give .unwrap() and .expect() a tiny chance, like 0.1%, to trigger anyway, even when the Option is Some (opt out via configuration).

Re: Several core problems with Rust

#235

Post by tialaramex »

Dylan16807 wrote: post #184
Capricorn2481 wrote: post #156

Earlier quoted context omitted.

> Things having unsafe {...} does not make them unreliable. On the contrary, if you run into a memory issue in a rust program, you know where to look for it This isn't true, no matter how much people keep saying it. Unsafe does not scope bugs to the block, or even where you have to look for bugs. Just having unsafe in your codebase means changing code outside the unsafe block could cause UB. Doesn't mean I think it's…

If changing the safe code causes UB, the actual bug is in the unsafe code.

This is very true from outside an encapsulation, but within the private implementation of a type there may be safe Rust that's required to uphold some assumptions made by the unsafe Rust [if there is some] and while in theory the bug is in the incorrect assumption made by the unsafe Rust in practice we're going to fix the "safe" code which broke our assumption instead.

Re: Several core problems with Rust

#236

Post by imtringued »

Capricorn2481 wrote: post #156
lordnacho wrote: post #54

I tend to disagree. - Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile. Let rust-analyzer tell you if there are errors before you even try compiling. Let your CI do release optimization in its own time, who cares if CI is slow? - The cloudflare bug was not caused by rust. Every language…

> Things having unsafe {...} does not make them unreliable. On the contrary, if you run into a memory issue in a rust program, you know where to look for it This isn't true, no matter how much people keep saying it. Unsafe does not scope bugs to the block, or even where you have to look for bugs. Just having unsafe in your codebase means changing code outside the unsafe block could cause UB. Doesn't mean I think it's…

This is true. If you consider unsafe memory to be a separate region in Rust, your safe Rust code can still have pointers to unsafe memory. The only solution to this problem is to perform some sort of validation of the returned data structures every time they are returned by an unsafe block.

Re: Several core problems with Rust

#237

Post by ameixaseca »

fhap wrote: post #117
delifue wrote: post #112

The biggest value of Rust is to avoid heisenbug https://en.wikipedia.org/wiki/Heisenbug Memory safety and thread safety are causes of heisenbugs. However there are other causes. Rust don't catch all heisenbug. But not being perfect doesn't mean it's useless (perfect solution fallacy). The article has some valid points but is full of ragebait exaggeration.

> The article has some valid points but is full of ragebait exaggeration. Given that Rust doesn’t always have critiques that are backed with evidence, this wasn’t bad. People can use C now that LLMs make it easier, so Rust is no longer needed in many ways.

> Given that Rust doesn’t always have critiques that are backed with evidence, this wasn’t bad.

What evidence?

Re: Several core problems with Rust

#238

Post by ameixaseca »

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…

> There must be a name for that sort of fallacy.

Motivated reasoning

Re: Several core problems with Rust

#239

Post by gr4vityWall »

nicce wrote: post #25
gr4vityWall wrote: post #9

The author would probably find joy in using Zig. Personally my biggest complain from Rust is that I wish it was more readable. I've seen function signatures that seemed straight out of C++.

> Personally my biggest complain from Rust is that I wish it was more readable. I've seen function signatures that seemed straight out of C++. There is always a trade-off. You really cannot provide enough information for the compiler without the current signatures. There is a certain point where you cannot compress the information without losing some features.

I fully believe you, I don't know what the solution would be either.

Re: Several core problems with Rust

#240

Post by anarki8 »

> Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times.

I am more concerned about correctness and "zero-cost abstraction" of the end result, if sacrificing few seconds of compilation time is necessary for that - fine by me.

> It’s complex. Just as complex as C++. But C++ had legacy and Rust had not. The complexity of forcing your way through the jungle of Arc>> on every single step directly impacts the quality of the logic being implemented i.e. you can’t see the forest for the trees. Once again, C++ has the same problem, so what’s the point of the language switch in the end?

So, you seem to prefer data races and dangling pointers, or? Have you tried "actors-like" channels+rayon approach if you hate mutex so much?

> Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time.

You again prefer UB and/or corrupted state (and call that "reliability") over required explicit checks of Result via matching. This is definition of bad code to me.

> When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware), the performance of native Rust memory model is subpar

Few boundary checks sometimes add negligible overhead, but again you need those in any language to enforce correctness, Rust just adds those automatically.

Post reply on HN