Earlier quoted context omitted.
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…
> What about a medical procedure that WILL kill the patient if interrupted? What about life support in space? Hitting an assert in those kinds of systems is a very bad place to be, but an automatic halt is worse than at least giving the people involved a CHANCE to try and get to a state where it's safe to take the system offline and restart it. Kinda a strawman there. That's got to account for, what, 0.0001% of all u…
“Rust is safe” is not some kind of absolute guarantee of code safety
251–260 of 542 posts
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#252Earlier quoted context omitted.
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…
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#253Earlier 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?
And then there would be no Linux kernel. So much for companies.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#254I’ve been using Rust for a while, and I’m so, so tired of hearing this argument. Yes, we know. We get it. Rust is not an absolute guarantee of safety and doesn’t protect us from all the bugs. This is obvious and well-known to anyone actually using Rust. At this point, the argument feels like some sort of ideological debate happening outside the realm of actually getting work done. It feels like any time someone says…
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#255Earlier 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…
I think history will show that we can do a lot better than C/C++ and Rust is one of the best steps yet to show that. Rust will be replaced by something better some day and the cycle will repeat.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#256Earlier quoted context omitted.
> Rust is not an absolute guarantee of safety and doesn’t protect us from all the bugs. That's not exactly the vibe I'm getting from the typical Rust fanboys popping up whenever there's another CVE caused by the usage of C or C++ though ;) Rust does seem to attract the same sort of insufferable personalities that have been so typical for C++ in the past. Why that is, I have no idea.
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…
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#257Earlier quoted context omitted.
> it's definitely not what he wrote. I feel like we must have read two different articles. You sound crazy. Didn't read it your way at all. > Think of that "debugging tools give a huge warning" as being the equivalent of std::panic in standard rust. Yes, the kernel will continue (unless you have panic-on-warn set), because the kernel MUST continue in order for that "report to upstream" to have a chance of happening.…
He wrote: > In the kernel, "panic and stop" is not an option (it's actively worse than even the wrong answer, since it's really not debugable), so the kernel version of "panic" is "WARN_ON_ONCE()" and continue with the wrong answer. (edit, and): > Yes, the kernel will continue (unless you have panic-on-warn set), because the kernel MUST continue in order for that "report to upstream" to have a chance of happening. Di…
The issue being discussed here is that Rust comes from a perspective of being able to classify errors and being able to automate error handling. In the kernel, it doesn't work like that, as we're working with more constraints than in userland. That includes hardware that doesn't behave like it was expected to.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#258Earlier quoted context omitted.
Or, in other words, rust-safety should mean what safety means in every other context, or rust people need to come up with a different word.
You don't get to change the definition of a term used by another when it had a clear meaning in its use, and then make an arugment on the basis that the author meant y when they clearly meant x. That is just conflation.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#259Earlier quoted context omitted.
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
#260Earlier quoted context omitted.
The kernel can’t fail to complete its operations, because then the entire system crashes and no logs are created. Instead, you can finish the operation and check the result.
panic doesn't instantly crash the program. It prints out debug information first. You could have kernel panics work the same way.