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

The state of the kernel Rust experiment

lwn.net

Post reply on HN
Print view View original

61–70 of 148 posts

Re: The state of the kernel Rust experiment

#61

Post by ivanbakel »

uecker wrote: post #52
simonask wrote: post #47

Earlier quoted context omitted.

You have a wild amount of confirmation bias going on here, though. Of course, this bug was in an `unsafe` block, which is exactly what you would expect given Rust's promises. The promise of Rust was never that it is magical. The promise is that it is significantly easier to manage these types of problems.

There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs." Of course, not everybody made such claims, but some did. Whether it is "significantly easier" to manage these types of problems and at what cost remains to be seen. I do not understand you comment about "confirmation bias" as did not make a quantitative prediction that could have bias.

> There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs."

Safe Rust does do this. Dropping into unsafe Rust is the prerogative of the programmer who wants to take on the burden of preventing bugs themselves. Part of the technique of Rust programming is minimising the unsafe part so memory errors are eliminated as much as possible.

If the kernel could be written in 100% safe Rust, then any memory error would be a compiler bug.

Re: The state of the kernel Rust experiment

#62

Post by grougnax »

Jean-Papoulos wrote: post #26

>Bergmann agreed with declaring the experiment over, worrying only that Rust still "doesn't work on architectures that nobody uses". I love you Arnd. More seriously, this will become an issue when someone starts the process of integrating Rust code into a core subsystem. I wonder whether this will lead to the kernel dropping support for some architectures, or to Rust doing the necessary work. Probably a bit of both.

The kernel must adapt to Rust, not the other way around. Rust is the way!

Re: The state of the kernel Rust experiment

#63

Post by Xylakant »

johncolanduoni wrote: post #58
uecker wrote: post #27

Earlier quoted context omitted.

I do not think it is weird. Every C bug was taken as clear evidence that we need to abandon C and switch to Rust. So the fact that there are also such bugs in Rust is - while obvious - also important to highlight. So it is not weird hatred against Rust, but hatred against bullshit. And considering that most of the code is C, your 150 C vulnerabilities is a meaningless number, so you still continue with this nonsense.

One C bug was not taken as clear evidence that we need to abandon C and switch to Rust. Hundreds of thousands of very similar bugs, over decades, in common code patterns were. I’ve never understood how other C or C++ developers could seriously question whether Rust solves any safety problems at all. Maybe the tradeoffs aren’t worth it for a particular use case, but how could you find it unimaginable that even just en…

> It’s mostly C and C++ developers trying to build a new option for solving their same problems.

I've observed that a lot of the folks I used to meet at ruby conferences have moved to Rust. No idea what led to this, but maybe it's just folks that were generally curious about new programming languages that moved to ruby when it became better known and that the same interest led to adopting Rust.

Re: The state of the kernel Rust experiment

#64

Post by Xylakant »

uecker wrote: post #49
bitwize wrote: post #40

Earlier quoted context omitted.

Safe Rust eliminates some of the more common memory bugs in C. The bug under discussion was written in unsafe Rust—but even that doesn't obviate the huge advantages Rust has over C. Even unsafe Rust, for instance, has far fewer UB gotchas than C. And with Rust, you can isolate the tricky bits in 'unsafe' blocks and write higher-level logic in safe Rust, giving your code an extra layer of protection. C is 100% unsafe—…

IMHO, "C is 100% unsafe" is a misleading way to look at it and the kind of exaggeration which I criticize. Also in C only specific language features are unsafe and not all code, and you can screen for these features and also isolate critical code in helper functions. Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust. I agree that "unsafe" is easier to f…

> Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust.

That's not true in practice: Unsafe code is clearly delineated and can be 100% correctly identified. In C, usage of dangerous features can occur at any point and is much harder to clearly separate.

Re: The state of the kernel Rust experiment

#65

Post by 0dayz »

bgwalter wrote: post #57
Certhas wrote: post #55

Earlier quoted context omitted.

Maybe you haven't been paying much attention in this space. Google found empirically that error density in _unsafe_ Rust is still much lower than in C/C++. And only a small portion of code is unsafe. So per LOC Rust has orders of magnitudes fewer errors than C/C++ in real world Android development. And these are not small sample sizes. By now more code is being written in Rust than C++ at Google: https://security.goo…

[flagged]

What does bias have to do with empirical evidence? Disprove that than driveling about non-tech stuff.

Re: The state of the kernel Rust experiment

#66

Post by sprash »

CamouflagedKiwi wrote: post #59
sprash wrote: post #56

Earlier quoted context omitted.

[flagged]

I've done a bit of work with Rust, and while I did find some of the complexity frustrating, it wasn't _that_ bad. While I could sort of see some situation like you describe with a secret agenda from big tech, I think that probably requires significantly more cunning & organisation than they actually have around this stuff. It's not like Microsoft invented Rust - in fact it came from a relatively small corp in the fir…

It is irrelevant who invented Rust. The relevant fact is that it can be used as a tool to divide the community because of its very opinionated design. Systemd was equally opinionated and also caused huge division. Who is paying the bills of Poettering these days: Microsoft.

The Halloween documents show that Microsoft is playing these games for a long time now. Who knows in which way they have advanced their psyops. Just because we can't read their E-mails anymore doesn't mean they stopped doing it.

Re: The state of the kernel Rust experiment

#67

Post by johncolanduoni »

Xylakant wrote: post #63
johncolanduoni wrote: post #58

Earlier quoted context omitted.

One C bug was not taken as clear evidence that we need to abandon C and switch to Rust. Hundreds of thousands of very similar bugs, over decades, in common code patterns were. I’ve never understood how other C or C++ developers could seriously question whether Rust solves any safety problems at all. Maybe the tradeoffs aren’t worth it for a particular use case, but how could you find it unimaginable that even just en…

> It’s mostly C and C++ developers trying to build a new option for solving their same problems. I've observed that a lot of the folks I used to meet at ruby conferences have moved to Rust. No idea what led to this, but maybe it's just folks that were generally curious about new programming languages that moved to ruby when it became better known and that the same interest led to adopting Rust.

I worked on a Ruby codebase that moved to Rust - I think that part is mostly cargo-culting cool things in the news to be perfectly honest. There’s type safety advantages, but if Ruby’s performance envelope was even conceivably acceptable for your use-case there are likely better options. I strongly suspect a lot of the friction between Rust and only-C/C++ developers is the product of a bunch of people coming at Rust from higher level languages parroting lines about safety, and then looking at you blankly if you ask how it handles nested pointer indirection.

But I don’t think that applies to the people actually driving the language forward, just those talking a big game on HN/Reddit.

Re: The state of the kernel Rust experiment

#68

Post by 0dayz »

sprash wrote: post #56
atoav wrote: post #41

If you build a house out of inflammable bricks instead of magnesium ones you can at least rule out magnesium fires. Now the question is: If we live in a world where magnesium fires are common, can we afford to not at least try building with the inflammable bricks? I know this topic stokes emotions, but if you haven't tried Rust as someone with C/C++ experience, give it a go. You will come out wiser on the other side,…

[flagged]

What project has been pushed to rewrite in rust that explicitly Microsoft has been the culprit in?

And not individuals who work at Microsoft does not count.

Re: The state of the kernel Rust experiment

#69

Post by sprash »

0dayz wrote: post #68
sprash wrote: post #56

Earlier quoted context omitted.

[flagged]

What project has been pushed to rewrite in rust that explicitly Microsoft has been the culprit in? And not individuals who work at Microsoft does not count.

> And not individuals who work at Microsoft does not count.

How in the world does this not count? People act in the interest of those who pay the bills.

Re: The state of the kernel Rust experiment

#70

Post by uecker »

Xylakant wrote: post #64
uecker wrote: post #49

Earlier quoted context omitted.

IMHO, "C is 100% unsafe" is a misleading way to look at it and the kind of exaggeration which I criticize. Also in C only specific language features are unsafe and not all code, and you can screen for these features and also isolate critical code in helper functions. Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust. I agree that "unsafe" is easier to f…

> Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust. That's not true in practice: Unsafe code is clearly delineated and can be 100% correctly identified. In C, usage of dangerous features can occur at any point and is much harder to clearly separate.

First, if "unsafe" worked so well 100% time, why did we have this bug? (and many other) So this already obviously wrong statement.

Then yes, you can use dangerous features in C at any time, but obviously you can also use "unsafe" at any time. The only difference is that "unsafe" is clearer to recognize. But how much this is worth is unclear. First, if you do not invalidly reduce the discussion to only memory safety, you need to review all other code anyway! But even then, it is also not true that only the code marked with "unsafe" is relevant. This is major myth. The "unsafe" code can cause UB outside "unsafe" and logic bugs outside "unsafe" can cause bugs unsafe. This does not perfectly decouple if you Rust repeat this nonsense over and over again.

Don't get me wrong, I think the unsafe keyword is good idea. But the magical powers Rust fans attribute to it and the "SAFETY" comment they put next to it tells me they are a bit delusional.

Post reply on HN