“Rust is safe” is not some kind of absolute guarantee of code safety • Hacker News Board

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

#221

Post by geertj » Sun, Oct 02, 2022, 4:26 PM UTC

titzer wrote: post #148

jmillikin wrote: post #137

Earlier quoted context omitted.

I think Linus's response would be that those failable tasks are called "processes", and the low-level supervisor that starts + monitors them is the kernel. If you have code that might fail and restart, it belongs in userspace. If you want to run an Erlang-style distributed system in the kernel then that's an interesting research project, but it isn't where Linux is today. You'd be better off starting with SeL4 or Fuc…

40 years of microkernels, of which I know Linus is aware of, beg to differ. Maybe Linus's extreme opposition to microkernels, ostensibly because they have historically a little lower performance--I dunno--but my comment should not be read as "yes, you must have a microkernel". There are cheaper fault isolation mechanisms than full-blown separate processes. Just having basic stack unwinding and failing a task would be…

> Just having basic stack unwinding and failing a task would be a start.

As the sibling comment pointed out, if you extend this idea to clean up all state, you end up with processes.

I do have some doubt on the no panic rule. But instead of emulating processes in the kernel, I’d see a firmware like subsystem whose only job it is to export core dumps from the local system, after which the kernel is free to panic.

As a general point and in my view, and I agree this is an appeal to authority, Linus has this uncanny ability to find compromises between practicality and theory that result in successful real world software. He’s not always right but he’s almost never completely wrong.

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

#222

Post by roywiggins » Sun, Oct 02, 2022, 4:27 PM UTC

pca006132 wrote: post #160

jrochkind1 wrote: post #126

Earlier quoted context omitted.

> but Rust also has no built-in mechanism to statically determine “this code won’t ever panic”, My intuition says that's the Halting Problem, so not actually possible to implement perfectly? https://en.wikipedia.org/wiki/Halting_problem

No, panic is not halting, you just need some static check to check that you never call some functions that can panic in your code. Essentially it is just checking if some code (panic) might be reachable, if it is not, it will never panic (but it can still do other crazy things). Note that we can only check for maybe, because in general we don't know if some code in the middle will somehow execute forever and never re…

Even if it is halting, you can sometimes statically detect if a Turing machine never halts. Just look through the state machine and see if any states will transition to a halt; if none of them do, the machine will loop forever. This is not a very large fraction of machines that loop forever, but if you're writing a machine and want to be absolutely sure it won't halt, just don't put in any states that halt.

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

#223

Post by coldtea » Sun, Oct 02, 2022, 4:28 PM UTC

jmull wrote: post #123

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. "the reality is that there are no absolute guarantees. Ever" Yeah, DUH! You calling his point BS, but also strongly agreeing with it. I guess you find it too obvious. But while it's obvious to many, there seem to be many who do not understand it. Issues involving rust often get derailed to pointlessness when rust's safety guarantees are treated as an absolute.

>You calling his point BS, but also strongly agreeing with it.

I'm only agreeing with the fact that there are no absolute guarantees. Not that his use of the fact in the point he makes has any relevance...

If somebody had said "The earth is round, therefore we should not care about getting lost and GPS, because you always can always keep going and end up where you started on a sphere anyway", then I would have also "stongly agreed" to the first factoid, but think the overall point BS.

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

#224

Post by gpm » Sun, Oct 02, 2022, 4:29 PM UTC

jmillikin wrote: post #147

jrochkind1 wrote: post #126

Earlier quoted context omitted.

> but Rust also has no built-in mechanism to statically determine “this code won’t ever panic”, My intuition says that's the Halting Problem, so not actually possible to implement perfectly? https://en.wikipedia.org/wiki/Halting_problem

If you were to define a subset of Rust's standard library (core + alloc + std) that does not contain the `panic!` macro, and excluded all functionality that needed to panic, then safe Rust could be proven to never panic (because it can't). That's different than solving the halting problem. You're not trying to prove it halts, you're just trying to prove it doesn't halt in a specific way, which is trivial to prove if…

> If you were to define a subset of Rust's standard library (core + alloc + std) that does not contain the `panic!` macro, and excluded all functionality that needed to panic, then safe Rust could be proven to never panic (because it can't).

Not quite, because stack overflows can cause panics independent of any actual invocation of the panic macro.

You need to either change how stack overflows are handled as well, or you need to do some static analysis of the stack size as well.

Both are possible (while keeping rust turing complete), so it's still not like the halting problem.

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

#225

Post by titzer » Sun, Oct 02, 2022, 4:29 PM UTC

aspaceman wrote: post #216

titzer wrote: post #173

Earlier quoted context omitted.

Well, you've edited your reply a couple times, so it's a moving target, but: > * Panic and shut it all down. This prevents any reporting mechanism like a core dump. You cannot attach a normal debugger to the kernel. No one is really advocating that. Clearly you need to be able to write code that fails at a smaller granularity than the whole kernel . See my comment upthread about what I mean by that: dynamic errors fa…

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.

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

#226

Post by jmull » Sun, Oct 02, 2022, 4:29 PM UTC

charcircuit wrote: post #114

zetaposter wrote: post #26

Earlier quoted context omitted.

Yeah ... Just reboot the machine and make me loose all my work, bro.

This is why programs automatically saving their state is important.

That's not a solution to OS instability.

Reliably saving state in the face of sudden total failure is both very tricky and app-specific. Just saving state changes automatically won't do it -- partial writes of complex state are likely to be inconsistent without luck or careful design and QA controls (tests, testing, on-going controls to ensure nothing new operates or relies on anything outside the safe state-saving mechanism).

It makes a lot more sense to put the effort into making the OS continue as well as it can, vs requiring every app to harden itself against sudden total failures.

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

#227

Post by coldtea » Sun, Oct 02, 2022, 4:29 PM UTC

peoplefromibiza wrote: post #119

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…

> Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus. In today's news "random angry guy on the Internet tells Linus Torvalds to go back to kindergarten, because reasons"

Actually Linus wrote the above part. It's a quote from his post.

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

#228

Post by acjohnson55 » Sun, Oct 02, 2022, 4:29 PM UTC

So much for Linus's time away to work on himself. It's disheartening to see how hard it is to change even when someone has the intention and resources to.

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

#229

Post by throw827474737 » Sun, Oct 02, 2022, 4:29 PM UTC

mynameisvlad wrote: post #144

aaaaaaaaaaab wrote: post #117

Earlier quoted context omitted.

>work environments It’s not a “work environment”. You can’t report Linus to HR. If you have a problem with him, you can fork the kernel and convince others to follow you. Then you’ll have a mailing list where you can ban Linus for his style. Good luck!

Yes because if he were at any company, he’d have been fired. Decades ago. Just because it’s not an official “work environment” per your definition does not mean it isn’t hostile or intolerable were it actually one. But actually countering that point is a lot harder, isn’t it?

> Yes because if he were at any company, he’d have been fired. Decades ago.

That's a pretty intolerable outright hostile and exclusive judgement :(

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

#230

Post by znpy » Sun, Oct 02, 2022, 4:29 PM UTC

Test0129 wrote: post #110

lucasyvas wrote: post #95

Earlier quoted context omitted.

It protects against the leading 70 percent of CVEs, which are due to memory safety issues. This is all Rust has ever claimed to solve and it's all I've ever seen anyone cite when advocating for it. If these people are insufferable to you, that I can't change your mind on. That said you might want to get used to it since major areas of industry are already considering C/C++ as deprecated (a paraphrasing from the Azure…

I didn't know the Azure CTO was the CTO was the C++ community. I'm sure the billions of lines of code written in C++ for the finance industry would love to have a word. The insufferable nature of the people isn't the advocating of safety. It's that Rust seems to have evolved a community of "X wouldn't have happened if Y was written in Rust!" and then walking away like they just transferred the one bit of knowledge ev…

> They occupy less than 1% of the programming community and act like they single-handedly are the only people who understand correctness.

Maybe I’m too young (just past 30) but is it just me or is that some kind of attitude that emerged in the last 10-15 years?

And I mean not only in programming, but in general.

A small amount of people which is very vocal about something and start pushing everybody else to their thing while simultaneously shaming and/or making fun of those who either disagree or aren’t generally interested.

I kinda see a pattern here.

Either way, it’s very annoying.

Going back to the rust topic… I recently started working with some software written in a mix of C++ and Java. I don’t own the codebase, I “just” have to get it working and keep it working. So i had to reach to another person for some performance issues and this guy starts the usual “should be rewritten in rust” … jesus christ dude, I don’t care for your fanboyism right know, either help me or tell me you won’t so I’ll looks somewhere else.

And of course, if as an outsider this is the experience I have to go through every time I deal with rust people… I’ll try to minimise my exposure to such people (and to the language, if necessary).