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

Rust in the kernel is no longer experimental

lwn.net

Post reply on HN
Print view View original

671–680 of 853 posts

Re: Rust in the kernel is no longer experimental

#671

Post by NetMageSCW »

mustache_kimono wrote: post #625
mrweasel wrote: post #242

Earlier quoted context omitted.

I'm curious as to which other metric you'd use to define successful? If it actual usage, C still wins. Number of new lines pushed into production each year, or new project started, C is still high up the list, would be my guess. Languages like Rust a probably more successful in terms of age vs. adoption speed. There's just a good number of platforms which aren't even supported, and where you have no other choice than…

> I'm curious as to which other metric you'd use to define successful? If it actual usage, C still wins. Wait, wait, you can use C everywhere, but if absolute lines of code is the metric, people seem to move away from C as quickly as possible (read: don't use C ) to higher level languages that clearly aren't as portable (Ruby, Python, Java, C#, C++, etc.)? > Rust can't target most platforms, and it compiles on even l…

Why do you think people are delighted/excited about Rust? Some people are, but I’m sure plenty of people are about C and Perl is well. Some people isn’t most people and certainly not all people.

Re: Rust in the kernel is no longer experimental

#672

Post by aw1621107 »

viraptor wrote: post #658
aw1621107 wrote: post #577

Earlier quoted context omitted.

It is how it's supposed to work. `unsafe` is intended to be used on functions where the caller must uphold some precondition(s) in order to not invoke UB, even if the keyword is not strictly required to get the code to compile. The general rule of thumb is that safe code must not be able to invoke UB.

Yes. I was objecting to the parent poster's "can and should be" which sounds like they think people just randomly choose where to use the unsafe decoration.

I can't say I got the same feeling. To me, the "Functions like that" lead-in indicated the opposite if anything since it implies some kind of reasoned consideration of what the function is doing.

Re: Rust in the kernel is no longer experimental

#673

Post by Xylakant »

menaerus wrote: post #662
Xylakant wrote: post #657

Earlier quoted context omitted.

It does, if you read the report and run a little (implied) math. The report says that their historical data gives them an estimate of 1000 Memory Safety issues per Million Lines of Code for C/C++. The same team currently has 5 Million lines of Rust code, of which 4% are unsafe (200 000). Assuming that unsafe Rust is on par with C/C++, this gives us an expected value of about 200 memory safety issues in the unsafe cod…

They say "With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC).". Do you honestly believe that there is 1 vulnerability per 5 MLoC?

1 memory safety vulnerability, that's a pretty important distinction.

Yes, I believe that at least the order of magnitude is correct because 4 800 000 of those lines are guaranteed to not have any by virtue of the compiler enforcing memory safety.

So it's 1 per 200 000, which is 1-2 orders of magnitude worse, but still pretty darn good. Given that not all unsafe code actually has potential for memory safety issues and that the compiler still will enforce a pretty wide set of rules, I consider this to be achievable.

This is clearly a competent team that's writing important and challenging low-level software. They published the numbers voluntarily and are staking their reputation on these reports. From personal observation of the Rust projects we work on, the results track with the trend.

There's no reason for me to disbelieve the numbers put forward in the report.

Re: Rust in the kernel is no longer experimental

#674

Post by NetMageSCW »

0xbadcafebee wrote: post #115
markus_zhang wrote: post #11

Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?

It's a bit like asking if there is any significant advantage to ICE motors over electric motors. They both have advantages and disadvantages. Every person who uses one or the other, will tell you about their own use case, and why nobody could possibly need to use the alternative. There's already applications out there for the "old thing" that need to be maintained, and they're way too old for anyone to bother with re…

Machine code: Yes. Punched cards: easy - every punch has the character it represents at the top of the card.

Re: Rust in the kernel is no longer experimental

#675

Post by menaerus »

Xylakant wrote: post #673
menaerus wrote: post #662

Earlier quoted context omitted.

They say "With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC).". Do you honestly believe that there is 1 vulnerability per 5 MLoC?

1 memory safety vulnerability, that's a pretty important distinction. Yes, I believe that at least the order of magnitude is correct because 4 800 000 of those lines are guaranteed to not have any by virtue of the compiler enforcing memory safety. So it's 1 per 200 000, which is 1-2 orders of magnitude worse, but still pretty darn good. Given that not all unsafe code actually has potential for memory safety issues an…

1 per 5M or 1 per 200K is pretty much unbelievable, especially in such a complex codebase, so all I can say then is to each their own.

Re: Rust in the kernel is no longer experimental

#676

Post by NetMageSCW »

anticrymactic wrote: post #163
vbezhenar wrote: post #82

Earlier quoted context omitted.

For my hobby code, I'm not going to start writing Rust anytime soon. My code is safe enough and I like C as it is. I don't write software for martian rovers, and for ordinary tasks, C is more ergonomic than Rust, especially for embedded tasks. For my work code, it all comes down to SDKs and stuff. For example I'm going to write firmware for Nordic ARM chip. Nordic SDK uses C, so I'm not going to jump through infinite…

> Just like C++ never killed C, despite being perfect replacement for it I think c++ didn't replace C because it is a bad language. It did not offer any improvements on the core advantages of C. Rust however does. It's not perfect, but it has a substantially larger chance of "replacing" C, if that ever happens.

I don’t agree that C++ is a bad language, though it has been standardized to death into a bad language. But the whole point is for C++ to not be worse than C while offering a lot more, which I think it does well. Of course, my last serious use of C++ was a little after release E…

Re: Rust in the kernel is no longer experimental

#677

Post by bigstrat2003 »

pjmlp wrote: post #246
ZeWaka wrote: post #142

Earlier quoted context omitted.

Yeah, not sure what they're saying... I use bitfields in multiple of my rust projects using those macros.

Across binary libraries ABI, regardless of static or dynamically linked?

Dynamic linking is not something you do in general in Rust. It's possible, but the compiler currently does not guarantee a stable ABI so it's not something one generally does.

Re: Rust in the kernel is no longer experimental

#678

Post by [deleted] »

menaerus wrote: post #668
baq wrote: post #647

Earlier quoted context omitted.

literally from the quote: unsafe{} doesn't actually disable all or even most of Rust’s safety checks (a common misconception).

They also say The practice of encapsulation enables local reasoning about safety invariants. which is not fully correct. Undefined behavior in unsafe blocks can and will leak into the safe Rust code so there is nothing there about the "local reasoning" or "encapsulation" or "safety invariants". This whole blog always read to me as too much like a marketing material disguised with some data so that it is not so obviou…

[deleted]

Re: Rust in the kernel is no longer experimental

#679

Post by steveklabnik »

estebank wrote: post #624
steveklabnik wrote: post #597

Earlier quoted context omitted.

For what it’s worth, I perceived hostility here a long time ago, but those people have pretty explicitly come around since. That said I also think the parent is just wrong to focus on gcc vs llvm as the source of that, and also to bring it up at this point regardless.

The only thing I could ever see misconstrued of as "hostility" with my earshot from anyone in t-compiler is myself saying something along the lines of "that sounds like a lot of effort that doesn't gain much over rustc_codegen_gcc, and I am not interested in contributing to a cpp codebase". Note that nowhere in my position I state anything like "this shouldn't exist" or "they should stop" or "we shouldn't cooperate".…

Yes, I'm being vague here because I don't think it's productive to bring up some old stuff, but I bring up at at all because I was trying to agree with you: at this point, it appears to be very fine and healthy, even if I didn't think that was 100% the case at one point.

If you really want to know, we can email about it, but I don't think it matters, because whatever it was is clearly under the bridge by now.

Re: Rust in the kernel is no longer experimental

#680

Post by littlestymaar »

NetMageSCW wrote: post #667
Ygg2 wrote: post #327

Earlier quoted context omitted.

It removes a class of security vulnerabilities, modulo any unsound unsafe (in compiler, std/core and added dependency). In practice you see several orders of magnitude fewer segfaults (like in Google Android CVE). You can compare Deno and Bun issue trackers for segfaults to see it in action. As mentioned a billion times, seatbelts don't prevent death, but they do reduce the likelihood of dying in a traffic accident.…

“by removing the nastiest class of security vulnerabilities” and “reduce the likelihood” don’t seem to be in the same neighborhood.

Dividing their number by 1000[1] is technically the later but in practice it's pretty much the former.

[1]: this the order of magnitude presented in the recent Android blog post: https://security.googleblog.com/2025/11/rust-in-android-move...

> Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction.

Post reply on HN