Live data from Hacker News

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

lkml.org

141–150 of 542 posts

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

#141

> 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…

> Aborting an operation is much better than incorrect results.

Depends. Is a kernel panic better than something acting wrongly? I prefer my kernel not to panic, at the expense of some error somewhere that may or may not crash my system.

If you look at the output of `dmesg` on any Linux system you often will see errors even in a perfectly working system. This is because programs of that size are by definition not perfect, there are bugs, the hardware itself has bugs, thus you want the system to keep running even if something is not working 100% right. Most of the time you will not even notice it.

> First of all, making a problem both obvious and easier to solve is better.

It's the same with assertions: useful for debugging, but we all disable them in production, when the program is not in the hands of a developer but of the customer, since for a customer a system that crashes completely is worse than a system that has some bugs somewhere.

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

#142
post #68

Earlier quoted context omitted.

They probably are, in many cases. Rust’s community, in aggregate, have developed a reputation (earned, in my opinion). It’s too bad that the community don’t follow the leaders’ example in this regard. There are some quality, level-headed Rust advocates. They appear to be the minority.

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…

> At least they don't go around slandering programming language communities.

Not so sure about this. I see a good amount of acrimony toward C, C++, Go, Zig, etc. from the Rust side.

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

#143
post #44

Quoted post unavailable.

Who "has to" put up with Linus? Linux is open-source software. People who feel they are putting up with Linus can just `cp linux/ betterlinux/`. If it's actually better and Linus was holding things back by being an insufferabe cunt, they can expect a huge amount of people to switch to their fork as well.

Nobody "has to" have a job either. It's interesting how words can have different standards of necessity depending on how you contextualize them. Is a basketball player tall? If you asked his friend in the NBA after a game, he might say no because he's relatively short for an NBA player. Amongst everyone else, you'd say he is definitely tall.

So no, in the strict sense, you don't "have to" put up with linus, that's obviously not what I meant. Nobody "has to" put up with anyone, ever. If you want to work on the linux kernel though, you do. Otherwise, you have to do what you just said - you have to provide a better alternative which is a huge ask.

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

#144

Earlier quoted context omitted.

It’s crazy to think that advocating for reasonable, non-toxic people to work with receives this kind response. Inclusivity and non-hostile work environments should not be considered “perfect” and “all-inclusive”. They should be basic . The default . The lowest bar possible .

>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?

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

#145

Quoted post unavailable.

You mean for the hundreds of thousands of people that in the past 31 years willingly decided to contribute to the to the most successful and well maintained open source project ever, because the creator is such a brilliant person?

Anyone who has to interact with him pretty much.

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

#146

Earlier quoted context omitted.

That shouldn’t excuse him from being a reasonably decent person to work with. He gets a lot more leeway than being the creator of Linux should afford someone.

Unreasonable people build things. Reasonable people run meetings.

Reasonable people also build things.

Unreasonable people also build things alone where everyone else doesn’t have to deal with them.

The world is hardly as black and white as you make it seem.

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

#147
post #99

Earlier quoted context omitted.

Please correct me if I’m wrong, but Rust also has no built-in mechanism to statically determine “this code won’t ever panic”, and thus with regards to Linux kernel requirements isn’t safer in that aspect than C. To the contrary, Rust is arguably less safe in that aspect than C, due to the general Rust practice of panicking upon unexpected conditions.

> 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 you first make it impossible.

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

#148
post #127

Earlier quoted context omitted.

The way to handle this is split up kernel work into fail-able tasks [1]. When a safety check (like array OOB) occurs, it unwinds the stack up to the start of the task, and the task fails. Linus sounds so ignorant in this comment. As if no one else thought of writing safety-critical systems in a language that had dynamic errors, and that dynamic errors are going to bring the whole system down or turn it into a brick.…

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 a start.

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

#149
post #68

Earlier quoted context omitted.

They probably are, in many cases. Rust’s community, in aggregate, have developed a reputation (earned, in my opinion). It’s too bad that the community don’t follow the leaders’ example in this regard. There are some quality, level-headed Rust advocates. They appear to be the minority.

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…

Threats? Slander? Do you feel that you're "speaking for a community" here?

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

#150
post #97

Earlier quoted context omitted.

It’s crazy to think that advocating for reasonable, non-toxic people to work with receives this kind response. Inclusivity and non-hostile work environments should not be considered “perfect” and “all-inclusive”. They should be basic . The default . The lowest bar possible .

Which is worse? a) Having poor communication skills. b) Describing people as toxic.

Well the latter isn't a bad thing so the former, I guess?
Post reply on HN