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

“Rust is safe” is not some kind of absolute guarantee of code safety

lkml.org

Post reply on HN
Print view View original

231–240 of 542 posts

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#231

Post by coldtea »

jstimpfle wrote: post #105
coldtea wrote: post #61

> And the reality is that there are no absolute guarantees. Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus. I thought that he had apologised and regretted being hostile in comments. Apparently not. Not that I have much of an issue with ranty…

> The point he makes is BS. > Yeah, DUH! > Well, if Linus doesn't realize Bordering the hypocritical... And I got the impression you missed his point as well.

>Bordering the hypocritical...

Only if one can't separate a trivial factoid being used in an argument with the quality of the argument itself and the point being made...

You, know, you can agree that "there are no absolute guarantees" while still considering it a BS argument to use this fact to support that having the (non-absolute) guarantees Rust does give is in any way less useful...

You can also disagree that "there are no absolute guarantees", while true, has any place to be used in an argument against the use of safer compilers...

That's of: "There are no absolute guarantees against dying from a crash, and safety belts don't give you any, so let's not use safety belts either" quality

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#232

Post by snovv_crash »

swinglock wrote: post #121
blinkingled wrote: post #79

> Even "safe" rust code in user space will do things like panic when things go wrong (overflows, allocation failures, etc). If you don't realize that that is NOT some kind of true safely[sic], I don't know what to say. > Not completing the operation at all, is not really any better than getting the wrong answer, it's only more debuggable. What Linus is saying is 100% right of course - he is trying to set the expectat…

At least in user space, aborting an operation is much better than incorrect results. But the kernel being incorrect makes user space incorrect as well. First of all, making a problem both obvious and easier to solve is better. Nothing "only" about it - it's better. Better both for the programmers and for the users. For the programmer the benefit is obvious, for the user problems will simply be more rare, because the…

It depends if you care more about correctness of this one single component, relative to uptime of the entire system.

A panic caused by the formatting in a rarely used log output taking down all of a large company's NTP servers simultaneously, for example, would not be seen as a reasonable tradeoff.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#233

Post by layer8 »

hegelstoleit wrote: post #204
layer8 wrote: post #154

Earlier quoted context omitted.

I’m referring to the fact that ubiquitous functions like unwrap() panic if the programmer has made an error. Guarding against such panics is outside of the scope of Rust-the-language, and has to be handled through external means. There are linters for C as well.

Linters can catch panics, linters for C won't catch memory issues which is what rust prevents.

Linters like Splint [0] (predating Rust) can do that for C. I’m not saying that Rust’s built-in approach isn’t better, but please be careful about what exactly you claim.

[0] http://splint.org/

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#234

Post by [deleted] »

titzer wrote: post #225
aspaceman wrote: post #216

Earlier quoted context omitted.

Ease the snark space ranger. > dynamic errors fail smaller granularity tasks and handlers deal with tasks failing due to safety checks going bad. Yes and that's why Rust is bad here (but it doesn't have to be). Rust _forces_ you to stop the whole world when an error occurs. You cannot fail at a smaller granularity. You have to panic. Period. This is why it is being criticized here. It doesn't allow you any other gran…

> You cannot fail at a smaller granularity. Rust needs to fix that then. So we agree on that.

[deleted]

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#235

Post by Tomte »

mike_hock wrote: post #202
EdSchouten wrote: post #138

Earlier quoted context omitted.

The policy of ‘oopsing’ and limping on is, in my opinion, literally one of Linux’s worst features. It has bitten me in various cases: - Remember when Linux had that caused the kernel to partially crash and eat 100% CPU due to some bug in the leap second application code? That caused a >1MW spike in power usage at Hetzner at the time. That must have been >1GW globally. Many people didn’t notice it immediately, so it m…

So instead of a power spike, we'd have had a major internet outage across the world, across the entire industry and beyond, probably, if everyone had panicked on oops. The blame really lies with people not monitoring their systems. As you said, you have the option to reboot on panic, but Linus is absolutely not wrong that this size does not fit all. What about a medical procedure that WILL kill the patient if interru…

You won't see Linux in those fields. I'm aware of a project by OSADL to qualify Linux for SIL 2, but your examples are way beyond that.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#236

Post by jstimpfle »

WastingMyTime89 wrote: post #159
Test0129 wrote: post #100

Earlier quoted context omitted.

I wouldn't say the Rust community parallels the C++ community in any way. The rust community is more like the insufferable Haskell/FP community who, despite producing very little measurable commercial value continue to look down on everyone else. Indeed, there's a lot of damage control going on in this thread walking back Rust's guarantees of safety despite that, up until this point, being Rust's only real selling po…

> Haskell/FP community As someone who worked on a lot of OCaml projects, I would like to assure you that the issue really is the Haskell community which I too find completely unbearable. The rest of the FP community is far nicer/less smug. For a long time, they just thought it was a shame some innovative constructs seemed to be stuck in their favourite languages (first class functions, variant types, inference) and n…

To be fair, the Haskell hype train has long passed, and I never perceived the Haskell community as insufferable. They're just preconcerned formulating everything in way too mathsy frameworks to the point of being extremely inproductive as from a "real world" programmer's perspective.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#237

Post by pwinnski »

tialaramex wrote: post #132

I don't think I buy Linus' high level claim. It is not necessarily better to press on with the wrong answer, in some cases failure actually is an option and might be much better than oops we did it wrong. This morning I was reading about the analysis of an incident in which a London tube train drove away with open doors. Nobody was harmed, or even in immediate danger, the train had relatively few passengers and in fa…

Linus' statement are applicable to the kernel only, and if we're using tube analogies, he was talking more about situations where the train is underway and something fails. The Rust way would be to panic, train stops in between stations and must be rebooted to continue. Linus was saying no, you carry on despite the error until you get to the next station. Much as the passengers in your story did.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#238

Post by Ar-Curunir »

shepardrtc wrote: post #167
mustache_kimono wrote: post #115

Earlier quoted context omitted.

At least they don't go around slandering programming language communities. If we're going to be serious about who is being toxic, it's definitely Linus in this thread. Guy makes first mistake (by a very broad interpretation of "mistake". Perhaps "misunderstanding"?). Linus goes nuclear. And while his reasoning is sound, his argumentation cycles between threats, bad-faith arguments, and just plain old yelling. What so…

> Linus goes nuclear. And while his reasoning is sound, his argumentation cycles between threats, bad-faith arguments, and just plain old yelling. In my opinion, in the software world, there is a large number of people who are very convinced of their own correctness. When they do something wrong or are simply mistaken, a gentle correction doesn't work. Linus is probably used to dealing with these people. I'm not sayi…

> In my opinion, in the software world, there is a large number of people who are very convinced of their own correctness. When they do something wrong or are simply mistaken, a gentle correction doesn't work.

Too bad there was no around to do that to Linus; maybe he'd finally realize that being an asshole is generally not a correct response.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#239

Post by Veliladon »

layer8 wrote: post #208
Veliladon wrote: post #187

Earlier quoted context omitted.

I think I prefer Rust's way of doing things. Just last night I used the Vec! macro incorrectly putting in a comma instead of a semi-colon and despite the program compiling correctly, it immediately panicked with an OOB error. With C it would have been a lot harder to even notice a bug little alone track it down.

Right. My personal opinion is that exceptions provide a better trade-off between catching bugs and still allowing the chance of graceful shutdown or recovery.

In my case it wouldn't have raised an exception though, it would have just been UB.

It's not like there's not exceptions in Rust though. The error handling is thorough to a fault when it's used. Unwrap is just a shortcut to say "I know there might be bad input, I don't want to handle it right now, just let me do it and I'll accept the panic."

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#240

Post by ChrisSD »

Someone1234 wrote: post #188
ChrisSD wrote: post #71

Earlier quoted context omitted.

What is better: continuing to "limp along" in some unknown corrupted state (aka undefined behaviour) or in a well defined (albeit invalid) state?

This question is answered in Linus' emails fully and better than I'm going to do. But to restate briefly, the answer varies wildly between kernel and user programs, because a user program failing hard on corrupt state is still able to report that failure/bug, whereas a kernel panic is a difficult to report problem (and breaks a bunch of automated reporting tooling). So in answer: Read the discussion.

You seem to have misunderstood me. The distinction I'm making is not between kernel panic or undefined behaviour. The distinction is between undefined behaviour and defined behaviour. That defined behaviour can be anything, even including "limping on" somehow.
Post reply on HN