> You put it in quotes and didn't mention any paraphrasing. Linus didn't write it.
I think it's a fair characterization of what was said. Feel free, as everyone is, to read the entire thread again. I'm not a journalist. You have the primary source at your finger tips!
> Can you point out the normative document that provides these guarantees?
> "If Rust people don't get this, we will have to part ways."
What are you quoting? I don't see this anywhere in the thread.
The nearest I see is:
If you cannot get over the fact that the kernel may have other
requirements that trump any language standards, we really can't work
together.
A reasonable, politely delivered, statement directed to an individual as opposed to Rust. It was in response to this rather cringy bit of lecturing:
No one is talking about absolute safety guarantees. I am talking about
specific ones that Rust makes: these are well-documented and formally
defined.
Rust has no formal language specification yet. It's still "an area of research," to paraphrase what is said when the question is asked. No defined memory model either; from the current Rust reference:
Rust does not yet have a defined memory model. Various academics
and industry professionals are working on various proposals, but
for now, this is an under-defined place in the language.
One could argue (not me; I'm far too pragmatic for such things) that Linus is being exceptionally generous in entertaining Rust in its current state.
> I feel like he’s under the impression that Rust-advocating contributors are putting Rust’s interests (e.g. “legitimizing it” by getting it in the kernel) above the kernel itself.
I mean the post Linus initially responded to did contain[1] a patch removing a kernel define, asking if anyone had any objections over removing that define, just to make the resulting Rust code a little nicer looking.
>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...
The point he makes is BS. "the reality is that there are no absolute guarantees. Ever" Yeah, DUH! The compiler could have bugs and soundness issues for example.
The point is you don't need "absolute guarantees" just "way safer and which dozens more classes of issues discovered automatically" is already enough. The other guy didn't write about "absolute guarantees". He said "WE'RE TRYING to guarantee the absence of undefined behaviour". That's an aim, not a claim they've either achieved it, or they can achieve it 100%
>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, I don't know what to say.
Well, if Linus doesn't realize this is irrelevant to the argument the parent made and the intention he talked about, I don't know what to say...
> Is the issue primarily with parent’s less than substantial comment
I would assume this, but also
> is there some issue with the underlying empirical analysis of Rust’s library codebase?
this is hard to tell, because
> The paper, upon which the video is based is linked in the description and is easily accessed
I don't think this is true, or else, I am missing it somehow. Where is the paper? I don't see it linked from the page that's linked in the description, and a quick google of the title didn't turn it up for me either.
>A big problem with Rust right now is that the documentation is awful.
Wha? Steve has been putting a ton of effort into it and it shows... When is the last time you looked? If you're one of these people that wants to announce your opinion in every thread and remind us that you've said them before, it would be worthwhile to keep up with the evolving language.
How you can understand Rust's lifetime tracking requirements and not understand why "unsafe" is needed...
Just grep through std lib for usages of "unsafe" and see why it's needed.
> However, i don't think anything you said changes their discussion, actually.
How does it not? It seems to me that OP revealed an alternative method of error handling (which is very cool I might add), exactly in response to Google's discussion on Rust's error handling.
If the discussion doesn't address this, then it seems reasonable to say it's incomplete, as its omission makes it appear they're not debating Rust at its strongest.
> If the author wanted an explanation for a technical decision, they could open an issue and have a conversation like an adult.
Opening an issue comes across as a whole lot more aggressive to me. That implies that they owe you an explanation or you want them to change their code.
> They cry about the existence of some unsafe code, but don’t actually put in the effort to figure out if it can lead to a real problem like unsoundness.
unsafe might as well be unsound. The key benefit of Rust is supposed to be better memory safety than C; if everything is using unsafe, why bother?
> If the demonstrated complacency of Rust coders toward potential bugs
lol what?
This is so very the opposite of my 6+ years of experience in Rust, where the community has a serious focus on testing, and great tooling support for it as well.
I honestly can't take anyone seriously who thinks that adding Rust to the kernel will increase security bugs. I just can't imagine they know anything about Rust, security, or the kernel.
>if you arbitrarily decide that "safe" means "memory safe" specifically and no other kind of "safe".
This is how Rust has always defined it. Linus is specifically saying that "Rust people" don't understand what "safe" is but... they do, he doesn't. He could say "Rust defines it as X, the kernel needs Y" but he doesn't say that, he implies that Rust people just don't understand the word "safe" or that they think Rust is safer than it is, which is simply not true. As I said, quite ironic given history.
> I wouldn't blame their discussion partners for not knowing what the developer means when they talk about some code being "safe".
I mean, I would definitely blame them if they're also going to go on an insulting rant about their definition being wrong.
> without people getting too hot under the collar about their personal hang-ups
Impossible, in my opinion, until a ton of people retire.
> I find it funny and think it's pretty telling that there are bold claims made that are only crossed out after the author is corrected
... What else would you expect? The author observed something, drew a mistaken conclusion, wrote it up, and then had the mistake pointed out, and so retracted. I can't imagine the author realised their claims were wrong before it was pointed out, so of course they're only going to cross them out after being corrected. Of course, it's rather unfortunate that an incorrect write-up is being upvoted to the top of HN but that's not the author's problem (other than the choice of the rather clickbaity title...).
For the specifics of this post, there's some subtle differences between how Rust and C++ behave that could easily explain how the author observed differing behaviour and thus jumped to the conclusion, as explored on /r/rust: https://www.reddit.com/r/rust/comments/63ijkw/rust_optimizat...
> From what I recall, Linux was also Linus doing something because he wanted to, not necessarily because there was a business driver. I'm not saying don't, its just good to understand the motivation.
People rewrite things in Rust, not because of business reasons, but because they want to. What’s different here?
> it is just that the borrow checker cannot verify the soundness of certain code
And I was just proving examples of such code for someone who asked. Honestly, some Rust folks get so defensive it makes them very prone to misinterpret simple factual statements about Rust as criticism.
Apparently you don’t disagree with any of the factual statements that I’m making. You just have some vague unsubstantiated feeling that I don’t ‘get’ Rust.
> The amount of time our industry wastes on C++isms is ridiculous where rust just works.
This implies that Rust doesn't have any problems, which is...crazy.
In addition to the problematic community, just rearchitecting your code to fit around the borrow checker can be a massive amount of work, which already makes it infeasible for use in some places where the primary work is not on greenfield projects but on legacy code.
> Unfortunately theres an old guard that refuses to let up and invest in rust.
...and this is just emotionally manipulative, in addition to incredibly dishonest about the problems that Rust actually has.
> You forcibly took a discussion in a different direction from what was originally being discussed, reframing everything to a strictly absolutist view of trust, and are somehow bewildered that folks aren't understanding what you're saying.
Huh? My trust model was the same as that of those who want memory to be zero'd, like the one earlier [1]. People ask for that because so many attacks we see today are in external libraries and kernel-mode, and hence people are worried about that. That is not something in my fantasy; that's the model of the world we live in. You guys decided to deliberately ignore that and pretend a safe language implies worrying about attacks in external code is ridiculous. I was trying to steer back the discussion to that model. Apparently I failed; you guys win. Rust programs are invincible by definition.
I think it's a fair characterization of what was said. Feel free, as everyone is, to read the entire thread again. I'm not a journalist. You have the primary source at your finger tips!
> Can you point out the normative document that provides these guarantees?
You're looking at the Rust reference right? https://doc.rust-lang.org/reference/behavior-considered-unde...
reply