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

451–460 of 853 posts

Re: Rust in the kernel is no longer experimental

#451

Post by linuxfax »

g947o wrote: post #435
rustoleum69 wrote: post #387

Earlier quoted context omitted.

[flagged]

I believe Linus responded to this very question. I recommend that you read through his email. Basically, technology evolves, and you or anyone else can't stop that just because you don't like it for whatever nonsense (non technical) reason.

He also said in that same email regarding Rust that:

> nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so.

So any argument that Rust would ever fully replace C in such a way that C would go away and be banned in the kernel is NOT what Linus said.

https://lkml.org/lkml/2025/2/20/2066

Re: Rust in the kernel is no longer experimental

#452

Post by Xylakant »

bgwalter wrote: post #415
anal_reactor wrote: post #410

Earlier quoted context omitted.

> Rust isn’t an invading tribe People doing open-source work often feel very tribal about their code and block ideas that are good but threaten their position in the community. Essentially same thing as office politics except it's not about money, it's about personal pride.

I'm sure that submitting a PR to a Rust project to rewrite parts in Ada/SPARK would be met with great enthusiasm.

Why? It depends on what you want to replace, but the Rust project has a long history of using tools written in other languages. Python is used a lot in build tooling, bors-ng was written in Elixir, llvm is written in c, ... gcc-rs doesn't contain a lot of rust code either, it's purely other languages according to https://github.com/Rust-GCC/gccrs

Fundamentally, if a tool is good and provides benefits then why not use it? You'll be met with concerns about maintainability if you just airdrop something written in Ada/SPARK, but that's fair - just as it was fair that the introduction of Rust in the linux kernel was indeed met with concerns about maintainability. It seems that those were resolved to the satisfcation of the group that decides things and the cost/benefit balance was considered net positive.

Re: Rust in the kernel is no longer experimental

#453

Post by freeopinion »

timschmidt wrote: post #428
_fe wrote: post #421

Earlier quoted context omitted.

In-general it seems that Rust proponents want ease and modernity to replace the ability to do the same in C better, with more control and intent, and with better results. Rust is less tight. That’s fine for an application, but the kernel is used by everyone who uses Linux. Rustians disparage C because it doesn’t have Rust behavior. Why must the kernel have Rust behavior?

> Rustians disparage C No, the 50+ years of ridiculously unavoidable memory corruption errors have done more to disparage C than anyone working in another language.

I don't think C should be disparaged at all. Just because I prefer torx screws doesn't mean phillips screws were a horrible idea. They were brilliantly simple and enormously effective. I can't think of a single situation in which I wouldn't prefer torx, but torx wasn't an option historically and phillips was not the wrong decision at the time. Times change.

Re: Rust in the kernel is no longer experimental

#454

Post by ndiddy »

gf000 wrote: post #355
jcranmer wrote: post #20

Earlier quoted context omitted.

C currently remains the language of system ABIs, and there remains functionality that C can express that Rust cannot (principally bitfields). Furthermore, in terms of extensions to the language to support more obtuse architecture, Rust has made a couple of decisions that make it hard for some of those architectures to be supported well. For example, Rust has decided that the array index type, the object size type, an…

> that C can express that Rust cannot The reverse is probably more true, though. Rust has native SIMD support for example, while in standard C there is no way to express that. 'C is not a low-level language' is a great blog post about the topic.

AFAIK std::simd is still nightly only. You can use the raw intrinsics in std::arch, but that's not any better than "#include ".

Re: Rust in the kernel is no longer experimental

#455

Post by weebull »

ramon156 wrote: post #353
dxroshan wrote: post #347

Earlier quoted context omitted.

Mostly GPU drivers

Rightfully so, its probably the place where you'll het most ROI

I don't understand why. Working with hardware you're going to have to do various things with `unsafe`. Interfacing to C (the rest of the kernel) you'll have to be using `unsafe`.

In my mind, the reasoning for rust in this situation seems flawed.

Re: Rust in the kernel is no longer experimental

#456

Post by weebull »

josephg wrote: post #407
johncolanduoni wrote: post #283

Earlier quoted context omitted.

Drivers are interesting from a safety perspective, because on systems without an IOMMU sending the wrong command to devices can potentially overwrite most of RAM. For example, if the safe wrappers let you write arbitrary data to a PCIe network card’s registers you could retarget a receive queue to the middle of a kernel memory page.

> if the safe wrappers let you write arbitrary data to a PCIe network card’s registers Functions like that can and should be marked unsafe in rust. The unsafe keyword in rust is used both to say “I want this block to have access to unsafe rust’s power” and to mark a function as being only callable from an unsafe context. This sounds like a perfect use for the latter.

So if you're writing a device driver in rust...

- Hardware access is unsafe - Kernel interface is unsafe

How much remains in the layer in-between that's actually safe?

Re: Rust in the kernel is no longer experimental

#457

Post by cmeacham98 »

iurbwdj wrote: post #445
josephg wrote: post #399

Earlier quoted context omitted.

If rust didn’t provide value to the Linux kernel, there’s no way it would have made out of the experimental phase. Rust isn’t an invading tribe. It’s just a tool.

[flagged]

Didn't Hector step down essentially as a direct result of that behavior? https://www.phoronix.com/news/Asahi-Linux-Lead-No-Upstream

Do you have an example of other R4L maintainers harassment? Because you've spammed the same single example 3-4 times on this post alone.

Re: Rust in the kernel is no longer experimental

#458

Post by Yossarrian22 »

linuxfax wrote: post #451
g947o wrote: post #435

Earlier quoted context omitted.

I believe Linus responded to this very question. I recommend that you read through his email. Basically, technology evolves, and you or anyone else can't stop that just because you don't like it for whatever nonsense (non technical) reason.

He also said in that same email regarding Rust that: > nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so. So any argument that Rust would ever fully replace C in such a way that C would go away and be banned in the kernel is NOT what Linus said. https://lkml.org/lkml/2025/2/20/2066

That’s a reasonable position today, but what about in 20 years?

Re: Rust in the kernel is no longer experimental

#459

Post by teekert »

grimgrin wrote: post #432
bpavuk wrote: post #340

Earlier quoted context omitted.

I am missing some context, did not follow the Linux/Rust drama. which guy?

linus torvalds

I can't find the movie, but there was a guy angry that stated that he should not have to learn Rust, nobody should. And Rust should not be in the kernel.

Re: Rust in the kernel is no longer experimental

#460

Post by MSFT_Edging »

bgwalter wrote: post #391
TazeTSchnitzel wrote: post #388

Earlier quoted context omitted.

Because someday the programming state of the art must advance beyond 1970, and someday we must stop introducing new memory safety bugs that cause horrific vulnerabilities, and for kernel code we don't have the luxury of recompiling everything with garbage collection turned on as a band-aid for C's incurable defects.

The Unix/C people wrote their own kernel in the 1970s instead of invading an existing one.

Back when the primary consumers of the kernel were other researchers. Not billions of machines running our society.
Post reply on HN