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

441–450 of 853 posts

Re: Rust in the kernel is no longer experimental

#441

Post by iurbwdj »

bayindirh wrote: post #411
iurbwdj wrote: post #395

Earlier quoted context omitted.

https://lkml.org/lkml/2025/2/6/1292

Some pretext: I'm a Rust skeptic and tired of Rust Evangelism Task Force and Rewrite in Rust movements. --- Yes. I remember that message. Also let's not forget what marcan said [0] [1]. In short, a developer didn't want their C codebase littered with Rust code, which I can understand, then the Rust team said that they can maintain that part, not complicating his life further (Kudos to them), and the developer lashing…

One perspective is that Rust appears to be forced into the Linux kernel through harassment and pressure. Instead of Rust being pulled, carefully, organically and friendly, and while taking good care of any significant objections. Objections like, getting the relevant features from unstable Rust into stable Rust, or getting a second compiler like gccrs (Linux kernel uses gcc for C) fully up and running, or ensuring that there is a specification (the specification donated by/from Ferrous Systems, might have significant issues), or prioritizing the kernel higher than Rust.

If I had been enthusiastic about Rust, and wanted to see if it could maybe make sense for Rust to be part of the Linux kernel[0], I would probably had turned my attention to gccrs.

What is then extra strange is that there have been some public hostility against gccrs (WIP Rust compiler for gcc) from the rustc (sole main Rust compiler primarily based on LLVM) camp.

It feels somewhat like a corporate takeover, not something where good and benign technology is most important.

And money is at stake as well, the Rust Foundation has a large focus on fundraising, like how their progenitors at Mozilla/Firefox have or had a large focus on fundraising. And then there are major Rust proponents who openly claim, also here on Hacker News, that software and politics are inherently entwined.

[0]: And also not have it as a strict goal to get Rust into the kernel, for there might be the possibility that Rust was discovered not to be a good fit; and then one could work on that lack of fit after discovery and maybe later make Rust a good fit.

Re: Rust in the kernel is no longer experimental

#442

Post by embedding-shape »

bgwalter wrote: post #430
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.

The "provide value" argument can be used for anything. Modern software politics and foundation sponsorship pressure are so complex that this argument may not even be true. It may be true in this case, but certainly you have seen corporate bloat being added to "open" source projects before.

> Modern software politics and foundation sponsorship pressure are so complex that this argument may not even be true.

May not, or may yes. As far as I know with my own interactions with the Linux kernel community, is that it's very different from typical "modern software politics", at least different enough that I'd make the claim they're special from the other communities.

If there is any community I'd assume makes most of their choices disregarding politics or pressures and purely on technical measures, it would be the Linux kernel community. With that said, no person nor community is perfect, but unless there is some hard evidence pointing to that the Linux people were forced to accept Rust into the kernel for whatever reason, then at least I'd refrain from believing in such theories.

Re: Rust in the kernel is no longer experimental

#443

Post by tambre »

barrucadu wrote: post #404
jenadine wrote: post #183

And yet, the Linux kernel's Rust code uses unstable features only available on a nightly compiler. Not optimal for ease of compilation and building old versions of the Kernel. (You need a specific version of the nightly compiler to build a specific version of the Kernel)

Don't the C parts of Linux heavily depend on GCC extensions too? Seems depending on specific compiler features isn't really a blocker.

The difference probably is that GCC extensions have been stable for decades. Meanwhile Rust experimental features have breaking changes between versions. So a Rust version 6 months from now likely won't be able to compile the kernel we have today, but a GCC version in a decade will still work.

Re: Rust in the kernel is no longer experimental

#444

Post by josephg »

accelbred wrote: post #180
J_Shelby_J wrote: post #97

Earlier quoted context omitted.

Complexity of Rust is just codifying existing complexity.

I've been working on Rust bindings for a C SDK recently, and the Rust wrapper code was far more complex than the C code it wrapped. I ended up ceding and getting reasonable wrappers by limiting how it can be used, instead of moddeling the C API's full capabilities. There are certainly sound, reasonable models of memory ownership that are difficult or impossible to express with Rust's ownership model. Sure, a differen…

I totally hear you about C friendly APIs not making sense in rust. GTK struggles with this - I tried to make a native UI in rust a few months ago using gtk and it was horrible.

> Also, a more Rust-friendly model would have incured higher memory costs.

Can you give some details? This hasn’t been my experience.

I find in general rust’s ownership model pushes me toward designs where all my structs are in a strict tree, which is very efficient in memory since everything is packed in memory. In comparison, most C++ APIs I’ve used make a nest of objects with pointers going everywhere. And this style is less memory efficient, and less performant because of page faults.

C has access to a couple tricks safe rust is missing. But on the flip side, C’s lack of generics means lots of programs roll their own hash tables, array lists and various other tools. And they’re often either dynamically typed (and horribly inefficient as a result) or they do macro tricks with type parameters - and that’s ugly as sin. A lack of generics and monomorphization means C programs usually have slightly smaller binaries. But they often don’t run as fast. That’s often a bad trade on modern computers.

Re: Rust in the kernel is no longer experimental

#445

Post by iurbwdj »

josephg wrote: post #399
bgwalter wrote: post #391

Earlier quoted context omitted.

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

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]

Re: Rust in the kernel is no longer experimental

#446

Post by embedding-shape »

amiga386 wrote: post #426
bmicraft wrote: post #292

Earlier quoted context omitted.

Which ones would that be?

https://lwn.net/Articles/1045363/ > Rust, which has been cited as a cause for concern around ensuring continuing support for old architectures, supports 14 of the kernel's 20-ish architectures, the exceptions being Alpha, Nios II, OpenRISC, PARISC, and SuperH.

> supports 14 of the kernel's 20-ish architectures

That's a lot better than I expected to be honest, I was thinking maybe Rust supported 6-7 architectures in total, but seems Rust already has pretty wide support. If you start considering all tiers, the scope of support seems enormous: https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

Re: Rust in the kernel is no longer experimental

#447

Post by pjmlp »

gjajric2 wrote: post #376
pjmlp wrote: post #352

Earlier quoted context omitted.

You show a lack of awareness that ISO C and C++ are also not applicable, because on those domains the full ISO language standard isn't available, which is why freestanding is a thing.

But freestanding is not experimental, unlike Embedded Swift according to Apple. And there are full, large OS kernels written in C and C++. You continue being undeniably, completely wrong.

Is it really? It always depends on which specific C compiler, and target platform we are talking about.

For Apple it suffices that it is fit for purpose for Apple itself, it is experimental for the rest of the world.

I love to be rightly wrong.

Re: Rust in the kernel is no longer experimental

#448

Post by kolektiv »

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.

If anyone submitted such a PR to one of my projects and could explain compelling benefits for why doing so would be a general improvement, even considering trade-offs of increased complexity/maintainability, etc., then I'd be delighted they'd cared enough to improve my software.

Re: Rust in the kernel is no longer experimental

#449

Post by weebull »

Imustaskforhelp wrote: post #213
simonask wrote: post #208

Earlier quoted context omitted.

What they mean is that the Linux kernel has a long-standing policy to keep the whole kernel compilable on every commit, so any commit that changes an internal API must also fix up _all_ the places where that internal API is used. While Rust in the kernel was experimental, this rule was relaxed somewhat to avoid introducing a barrier for programmers who didn't know Rust, so their work could proceed unimpeded while the…

So does this mean that the C developers might need to learn Rust or cooperate more with the rust developer team basically?

Learn rust to a level where all cross language implications are understood, which includes all `unsafe` behaviour (...because you're interfacing with C).

Yes it does.

Re: Rust in the kernel is no longer experimental

#450

Post by pjmlp »

bob1029 wrote: post #364
vlovich123 wrote: post #326

Earlier quoted context omitted.

Seems like game consoles for example has been accomplished by at least one dedicated team even if the vendor nor upstream provide official support: https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_ky... I’m sure if Rust becomes more popular in the game dev community, game consoles support will be a solved problem since these consoles are generally just running stock PC architectures with a normal OS and ther…

> Switch Good luck shipping arbitrary binaries to this target. The most productive way for an indie to ship to Nintendo in 2025 is to create the game Unity and build via the special Nintendo version of the toolchain. How long do we think it would take to fully penetrate all of these pipeline stages with rust? Particularly Nintendo, who famously adopts the latest technology trends on day 1. Do we think it's even worth…

Not only Unity, Capcom is using their own fork of .NET in their game engine.

Devil May Cry for the Playstation 5 was shipped with it.

Post reply on HN