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

641–650 of 853 posts

Re: Rust in the kernel is no longer experimental

#641

Post by seba_dos1 »

bayindirh wrote: post #373
chippiewill wrote: post #367

Earlier quoted context omitted.

That was a single message in a very large thread. It absolutely was not just about code quality.

Yes, that's the entry of the rabbit hole, and reader is advised to dig their own tunnel. I remember following the tension for a bit. Yes, there are other subjects about how things are done, but after reading it, I remember framing "code quality" as the base issue. In high-stakes software development environments, egos run high generally, and when people clash and doesn't back up, sparks happen. If this warning is ign…

marcan has even publicly ranted about having to send patches as e-mails. This rage quit simply concluded that journey.

Re: Rust in the kernel is no longer experimental

#642

Post by [deleted] »

menaerus wrote: post #640
kaoD wrote: post #632

Earlier quoted context omitted.

> Now, imagine where the highest concentration of bugs will be. And how many bugs there will be elsewhere. You're doing it again ! Doesn't matter where the majority of bugs will be. If you avoid the minority it's still an improvement . Also, Rust safety is not related at all to bugs . You seem to have a misunderstanding of what Rust is or what safe Rust provides. (Also, I'd challenge the rest of your assumptions, but…

What am I exactly doing again? I am providing my reasoning, sorry if that itches you the wrong way. I guess you don't have to agree but let me express my view, ok? My view is not extremist or polarized as you see. I see the benefit of Rust but I say the benefit is not what Internet cargo-cult programming suggests. There's always a price to be paid, and in case of kernel development I think it outweighs the positive s…

[deleted]

Re: Rust in the kernel is no longer experimental

#643

Post by metaltyphoon »

pjmlp wrote: post #236
biorach wrote: post #145

Earlier quoted context omitted.

There are certain styles of programming and data structure implementations that end up requiring you to fight Rust at almost every step. Things like intrusive data structures, pointer manipulation and so on. Famously there is an entire book online on how to write a performant linked list in idiomatic Rust - something that is considered straightforward in C. For these cases you could always use Zig instead of C

Given Zig's approach to safety, you can get the same in C with static and runtime analysis tools, that many devs keep ignoring. Already setting the proper defaults on a Makefile would get many people half way there, without changing to language yet to be 1.0, and no use-after-free story.

> many devs keep ignoring

And thats why Zig don’t offer much. Devs will just ignore it.

Re: Rust in the kernel is no longer experimental

#644

Post by bonzini »

cevious wrote: post #363
notachatbot123 wrote: post #192

Earlier quoted context omitted.

I was confused but then noticed the actual headline of the submitted page: "The end of the kernel Rust experiment"

Kind of tells you something about how timidly and/or begrudgingly it’s been accepted. IMO the attitude is warranted. There is no good that comes from having higher-level code than necessary at the kernel level. The dispute is whether the kernel needs to be more modern, but it should be about what is the best tool for the job. Forget the bells-and-whistles and answer this: does the use of Rust generate a result that i…

> Forget the bells-and-whistles and answer this: does the use of Rust generate a result that is more performant and more efficient than the best result using C?

These are the performance results for an NVMe driver written in Rust: https://rust-for-linux.com/nvme-driver

It's absolutely on par with C code.

Re: Rust in the kernel is no longer experimental

#645

Post by glenstein »

CursedSilicon wrote: post #614
iurbwdj wrote: post #394

Earlier quoted context omitted.

It involved large parts of the Rust community, and the famous Rust developer Hector Martin (with an alter ego of Asahi Lina, a female vtuber, which he appears irrationally embarrassed about), harassing others. Even Linus Torvalds called out Hector Martin. https://lkml.org/lkml/2025/2/6/1292 > On Thu, 6 Feb 2025 at 01:19, Hector Martin wrote: > > If shaming on social media does not work, then tell me what does, becaus…

Is there any evidence "Asahi Lina" is Hector?

Thank you for asking this. It was presented matter of fact and I would not have appreciated that it was something less than settled. The best I can find from googling was rumors and speculation (insert comment in reply with more rumors and speculation). I also don't necessarily think it means someone is a Bad Guy if true. I want people to be able to have anonymous alter egos online if that's what they want and they're not doing any harm.

Re: Rust in the kernel is no longer experimental

#646

Post by tracker1 »

jacquesm wrote: post #521
hollerith wrote: post #511

Earlier quoted context omitted.

Aren't large parts of a web browser and a runtime for a programming language also better written in Rust than in Go or Java?

I'd say no, access to a larger pool of programmers is an important ingredient in the decision of what you want to write something in. Netscape pre-dated Java which is why it was written in C/C++ and that is why we have rust in the first place. But today we do have Java which has all of the rust safety guarantees and then some, is insanely performant for network code and has a massive amount of mindshare and available…

Browsers already eat up GBs of ram... I don't want to know how bad it would get written in Java.

Re: Rust in the kernel is no longer experimental

#647

Post by baq »

zozbot234 wrote: post #570
Xylakant wrote: post #490

Earlier quoted context omitted.

It's great that the Google Android team has been tracking data to answer that question for years now and their conclusion is: ------- The primary security concern regarding Rust generally centers on the approximately 4% of code written within unsafe{} blocks. This subset of Rust has fueled significant speculation, misconceptions, and even theories that unsafe Rust might be more buggy than C. Empirical evidence shows…

> The practice of encapsulation enables local reasoning about safety invariants. > The additional scrutiny that unsafe{} blocks receive. None of this supports an argument that "unsafe Rust is safer than C". It's just saying that with enough scrutiny on those unsafe blocks, the potential bugs will be found and addressed as part of development. That's a rather different claim.

literally from the quote:

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

Re: Rust in the kernel is no longer experimental

#648

Post by tracker1 »

jacquesm wrote: post #554
hollerith wrote: post #538

Earlier quoted context omitted.

All the mainstream browsers do their own low-level graphics rendering (e.g., of text and icons and such). Is Java performant enough to do that?

Absolutely. Again, not a fan of the language. But you can transcode 10's of video streams on a single machine into a whole pile of different output resolutions and saturate two NICs while you're at it. Java has been 'fast enough' for almost all purposes for the last 10 years at least if not longer. The weak point will always be the startup time of the JVM which is why you won't see it be used for short lived processe…

Are the streams actually transcoded in Java, or is Java just orchestrating FFMpeg (and likely platform accelerators)?

Re: Rust in the kernel is no longer experimental

#649

Post by QuiEgo »

torginus wrote: post #636
goku12 wrote: post #177

Earlier quoted context omitted.

That's a rather pessimistic take compared to what's actually happening. What you say should apply to the big players like Amazon, Google, Microsoft, etc the most, because they arguably have massive C codebases. Yet, they're also some of the most enthusiastic adopters and promoters of Rust. A lot of other adopters also have legacy C codebases. I'm not trying to hype up Rust or disparage C. I learned C first and then R…

I'm curious why your perspective on Rust as a HW engineer. Hardware does a ton of things - DMA, interrupts, etc. that are not really compatible with Rust's memory model - after all Rust's immutable borrows should guarantee the values you are reading are not aliased by writers and should be staying constant as long as the borrow exists. This is obviously not true when the CPU can either yank away the execution to a di…

I’d like to take a swipe at this

Rust has no_std to handle not having an allocator.

Tons of things end up being marked “unsafe” in systems/embedded Rust. The idea is you sandbox the unsafeness. Libraries like zero copy are a good example of “containing” unsafe memory accesses in a way that still gets you as much memory safety as possible given the realities of embedded.

Tl;dr you don’t get as much safety as higher level code but you still get more than C. Or maybe put a different way you are forced to think about the points that are inherently unsafe and call them out explicitly (which is great when you think about how to test the thing)

Re: Rust in the kernel is no longer experimental

#650

Post by wat10000 »

gpm wrote: post #31
wat10000 wrote: post #22

Earlier quoted context omitted.

Most of the world uses other languages because they’re easier, not because they’re safer.

They're easier because, amongst other improvements, they are safer.

Sure, my point is the safety is not why they originally supplanted C and C++. It was seen largely as a tradeoff between ease of development and runtime performance. Memory safety as a goal of its own didn’t become prominent until much later.
Post reply on HN