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

481–490 of 853 posts

Re: Rust in the kernel is no longer experimental

#481

Post by archargelod »

drnick1 wrote: post #14
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?

Every system under the Sun has a C compiler. This isn't remotely true for Rust. Rust is more modern than C, but has it's own issues, among others very slow compilation times. My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.

One problem of Rust vs C, I rarely see mentioned is that Rust code is hard to work with from other languages. If someone writes a popular C library, you can relatively easily use it in your Java, D, Nim, Rust, Go, Python, Julia, C#, Ruby, ... program.

If someone writes a popular Rust library, it's only going to be useful to Rust projects.

With Rust I don’t even know if it’s possible to make borrow checking work across a language boundary. And Rust doesn't have a stable ABI, so even if you make a DLL, it’ll only work if compiled with the exact same compiler version. *sigh*

Re: Rust in the kernel is no longer experimental

#482

Post by galangalalgol »

marcusb wrote: post #438
bgwalter wrote: post #413

Earlier quoted context omitted.

[flagged]

https://www.redox-os.org/

Add in theseus, tock, hubris, and hermit-os. That is just the non academic ones. As for why none of them are widely used? Drivers. It wasn't that long ago redox didn't even support usb devices. The linux kernel is a giant mashup of oodles of drivers.

Re: Rust in the kernel is no longer experimental

#483

Post by maccard »

johncolanduoni wrote: post #103
mustache_kimono wrote: post #90

Earlier quoted context omitted.

> Every system under the Sun has a C compiler... My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative. This is still the worst possible argument for C. If C persists in places no one uses, then who cares?

You almost certainly have a bunch of devices containing a microcontroller that runs an architecture not targeted by LLVM. The embedded space is still incredibly fragmented. That said, only a handful of those architectures are actually so weird that they would be hard to write a LLVM backend for. I understand why the project hasn’t established a stable backend plugin API, but it would help support these ancillary arch…

How many of them are running Linux, and how many of them are running a modern kernel?

Re: Rust in the kernel is no longer experimental

#484

Post by Xylakant »

biqijf wrote: post #472
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.

Does this image count as significant tribalism in parts of the Rust community? https://github.com/microsoft/typescript-go/discussions/411#d... Taken from the above Github discussion regarding Go and Typescript. https://imgur.com/a/efdIuWb

How is the one comment from a GH account with 18 followers, no contribution to the Rust project (or any Rust based project at all) and mostly contributions to javascript projects in any way representative of the Rust community? Especially taken out of context - in context it seem like a failed(?) attempt at humor or sarcasm.

Do I treat your post from an obvious throwaway account created 13 minutes ago as somehow representative of the C community or the Linux kernel community or for that matter as representative of any community at all?

Come on, please. There's a ton of things that I consider worth of critisicm in the Rust community, but make a better case.

Re: Rust in the kernel is no longer experimental

#486

Post by Palomides »

muvlon wrote: post #425
bmicraft wrote: post #292

Earlier quoted context omitted.

Which ones would that be?

In order to figure this out I took the list of platforms supported by Rust from https://doc.rust-lang.org/nightly/rustc/platform-support.htm... and those supported by Linux from https://docs.kernel.org/arch/index.html , cleaned them up so they can be compared like for like and then put them into this python script: linux = { "alpha", "arc", "arm", "aarch64", "csky", "hexagon", "loongarch", "m68k", "microblaze", "mips…

some of the platforms on that list are not supported well enough to say they actually have usable rust, e.g m68k

Re: Rust in the kernel is no longer experimental

#487

Post by bmicraft »

muvlon wrote: post #425
bmicraft wrote: post #292

Earlier quoted context omitted.

Which ones would that be?

In order to figure this out I took the list of platforms supported by Rust from https://doc.rust-lang.org/nightly/rustc/platform-support.htm... and those supported by Linux from https://docs.kernel.org/arch/index.html , cleaned them up so they can be compared like for like and then put them into this python script: linux = { "alpha", "arc", "arm", "aarch64", "csky", "hexagon", "loongarch", "m68k", "microblaze", "mips…

Well, GCC 15 already ended support for the nios2 soft-core. The successor to it is Nios V which runs RISC-V. If users want us update the kernel, they'll also need to update their FPGA.

Microblaze also is a soft-core, based on RISC-V, presumably it could support actual RISC-V if anyone cared.

All others haven't received new hardware within the last 10 years, everybody using these will already be running an LTS kernel on there.

It looks like there really are no reasons not to require rust for new versions of the kernel from now on then!

Re: Rust in the kernel is no longer experimental

#489

Post by maccard »

weebull wrote: post #455
ramon156 wrote: post #353

Earlier quoted context omitted.

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.

I’ve done a decent amount of low level code - (never written a driver but I’m still young). The vast majority of it can be safe, and call into unsafe wrapped when needed. My experience is that a very very small amount of stuff actually needs unsafe and the only reason the unsafe C code is used is because it’s possible not because it’s necessary.

Re: Rust in the kernel is no longer experimental

#490

Post by Xylakant »

zozbot234 wrote: post #419
baq wrote: post #401

Earlier quoted context omitted.

> I don't know what one should even make from that statement. it's just a fact. by definition of the Rust language unsafe Rust is approximately as safe as C (technically Rust is still safer than C in its unsafe blocks, but we can ignore that.) > you didn't even bother to look at the code but still presented of course I did, what I've seen were one-liner trait impls (the 'whole traits' from your own post) and sub-line…

> technically Rust is still safer than C in its unsafe blocks This is quite dubious in a practical sense, since Rust unsafe blocks must manually uphold the safety invariants that idiomatic Safe Rust relies on at all times, which includes, e.g. references pointing to valid and properly aligned data, as well as requirements on mutable references comparable to what the `restrict` qualifier (which is rarely used) involve…

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 this to be quite wrong.

Our data indicates that even a more conservative assumption, that a line of unsafe Rust is as likely to have a bug as a line of C or C++, significantly overestimates the risk of unsafe Rust. We don’t know for sure why this is the case, but there are likely several contributing factors:

    unsafe{} doesn't actually disable all or even most of Rust’s safety checks (a common misconception).
    The practice of encapsulation enables local reasoning about safety invariants.
    The additional scrutiny that unsafe{} blocks receive.
-----

From https://security.googleblog.com/2025/11/rust-in-android-move...

Post reply on HN