Upcoming Rust language features for kernel development • Hacker News Board

Re: Upcoming Rust language features for kernel development

#161

Post by 0x457 » Thu, Oct 16, 2025, 6:37 PM UTC

School-Cotton wrote: post #130

William_BB wrote: post #65

Earlier quoted context omitted.

What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me? Speaking seriously, they surely meant data races, right? If so, what's preventing me from using C++ atomics to achieve the same thing?

> What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me? Well, pretty close to that, actually! Rust will statically prevent you from accessing the same data from different threads concurrently without using a lock or atomic. > what's preventing me from using C++ atomics to achieve the same thing You might forget?

Rust will also prevent you from sharing the unsharable between threads.

Re: Upcoming Rust language features for kernel development

#162

Post by kstrauser » Thu, Oct 16, 2025, 6:42 PM UTC

ameliaquining wrote: post #145

bobajeff wrote: post #100

Looking at the rust rfc for the lightweight clones feature [1]. It took me a while to sort of understand it. Once I did I was excited for the feature but after awhile I was once again struck by the observation that rust is a very complex language to learn. To me as someone who's not learned either it looks like all the concepts and features of 'true' modern C++ (as opposed to C + a few extra features) spliced with th…

Note that the community has somewhat soured on that particular proposal and it's probably not going to be enacted in its current form, precisely because it's so complicated. ( https://rust-lang.github.io/rust-project-goals/2025h2/ergono... ) Complexity is not necessarily an automatic dealbreaker for a Rust language proposal—lots of Rust features are complicated because they solve problems that don't admit simple solu…

As a side note, this might just be a me thing, but I distinguish between "complex" and "complicated". Certain things have an inherently complexity. Stripped to their essence, they're still going to have a lot of moving parts. It's just their nature. However, you can also add complication on top of something that makes it more complex than it needs to be to perform its function. Think "complication" in the watchmaker's sense. It might be neat to add a dial that shows the number of weeks since your last dentist appointment, but you don't really need that to have a functional wristwatch, and its presence makes the whole thing a lot more finicky and fragile than it would otherwise be.

Complexity is fine. Sometimes we're working on complex problems without simple, straightforward, correct solutions. I do try to avoid complications, though.

Re: Upcoming Rust language features for kernel development

#163

Post by kstrauser » Thu, Oct 16, 2025, 6:43 PM UTC

tredre3 wrote: post #160

vlovich123 wrote: post #134

Earlier quoted context omitted.

Aside from the complexity not being possible to misuse (which is trivial in C++), I still find it easier. Moreover, even if you didn’t know about this if you use clippy it’ll suggest construct replacements that are more idiomatic. So even if you didn’t know about lightweight clones, you’ll get suggestions to leverage them once they’re available for your codebase (and you can apply the vast majority trivially by askin…

> This is distinctly not a superpower c++ has and why the complexity I guess you don't have that much experience with actual C++ development? Because there's a plethora of static analysis tools and any serious IDE come with refactoring tools on top of that, both assistive and automated, that will suggest fixes as you type. Rust didn't invent anything with clippy, however good the tool might be...

I worked for Coverity and people paid us ludicrous amounts of money to get the kinds of suggestions that rustc and clippy give everyone for free. I'm a huge fan.

Re: Upcoming Rust language features for kernel development

#164

Post by misnome » Thu, Oct 16, 2025, 6:46 PM UTC

ameliaquining wrote: post #145

bobajeff wrote: post #100

Looking at the rust rfc for the lightweight clones feature [1]. It took me a while to sort of understand it. Once I did I was excited for the feature but after awhile I was once again struck by the observation that rust is a very complex language to learn. To me as someone who's not learned either it looks like all the concepts and features of 'true' modern C++ (as opposed to C + a few extra features) spliced with th…

Note that the community has somewhat soured on that particular proposal and it's probably not going to be enacted in its current form, precisely because it's so complicated. ( https://rust-lang.github.io/rust-project-goals/2025h2/ergono... ) Complexity is not necessarily an automatic dealbreaker for a Rust language proposal—lots of Rust features are complicated because they solve problems that don't admit simple solu…

I wonder if the block-level `clone(var_a, var_b)` was considered. It’s a bit verbose but very explicit and much better than the current situation.

Re: Upcoming Rust language features for kernel development

#165

Post by ameliaquining » Thu, Oct 16, 2025, 6:46 PM UTC

kstrauser wrote: post #162

ameliaquining wrote: post #145

Earlier quoted context omitted.

Note that the community has somewhat soured on that particular proposal and it's probably not going to be enacted in its current form, precisely because it's so complicated. ( https://rust-lang.github.io/rust-project-goals/2025h2/ergono... ) Complexity is not necessarily an automatic dealbreaker for a Rust language proposal—lots of Rust features are complicated because they solve problems that don't admit simple solu…

As a side note, this might just be a me thing, but I distinguish between "complex" and "complicated". Certain things have an inherently complexity. Stripped to their essence, they're still going to have a lot of moving parts. It's just their nature. However, you can also add complication on top of something that makes it more complex than it needs to be to perform its function. Think "complication" in the watchmaker'…

Yeah, I was slightly sloppy about that, but also the distinction doesn't entirely help at this level because people get into vicious fights about whether a particular bit of complexity is really "necessary". E.g., lots of people argue that async Rust is unnecessary complication, either because you can just write all the state machines by hand (which is terrible for expressiveness, but do you really need expressiveness?), or because you can just spawn an OS thread for every task (which is terrible for performance, but do you really need performance?). Whereas the pro-async perspective is, yes, it's very complex, but nothing simpler would have done everything that it needs to do.

Re: Upcoming Rust language features for kernel development

#166

Post by GeorgeTirebiter » Thu, Oct 16, 2025, 6:48 PM UTC

School-Cotton wrote: post #129

bobajeff wrote: post #100

Looking at the rust rfc for the lightweight clones feature [1]. It took me a while to sort of understand it. Once I did I was excited for the feature but after awhile I was once again struck by the observation that rust is a very complex language to learn. To me as someone who's not learned either it looks like all the concepts and features of 'true' modern C++ (as opposed to C + a few extra features) spliced with th…

Rust is more complex than C, yes, but as someone who has used both professionally, it is not even close to being as complex as C++. In fact it is closer in complexity to C than to C++.

Perhaps you can help guide a C expert but C++ avoider (and super-avoider of Rust, so far): If C is 1 in complexity, where does C++ and Rust fall. By 'complexity' here I mean: the ability to keep the Entire Language in your head at the same time. C, although it does have complex corners, is -- mostly -- not overly complicated. (As you can probably tell, I prefer assembly, because it is the least complicated. You can build your own abstractions up, which is the proper way to use assembly). Thank you for any insight; I'm not wedded to my views when shown a Better Way.

Re: Upcoming Rust language features for kernel development

#167

Post by chippiewill » Thu, Oct 16, 2025, 6:49 PM UTC

a-dub wrote: post #47

> The Rust for Linux project has been good for Rust i just decided do a good ol' 'find -name "*.rs"' in the kernel tree to get a sense for what all this is about. from what i can tell, there's just an api compatibility layer (found in /rust) and then a smattering of proof of concept drivers in tree that appear to just be simple rewrites of existing drivers (with the exception of the incomplete nvidia thing) that aren…

The point of the project is not meant to be an experiment in "programming language co-development", the point of the project is to use Rust in Linux kernel development. The project was started by Linux kernel developers who want to use Rust. It's been a slow start, but as you say, it's the world's most important piece of software so progress has been careful and trying to get the foundations right before going crazy with it.

The fact that Rust gets to benefit from the project too is just an added bonus.

Re: Upcoming Rust language features for kernel development

#168

Post by kstrauser » Thu, Oct 16, 2025, 6:49 PM UTC

ameliaquining wrote: post #165

kstrauser wrote: post #162

Earlier quoted context omitted.

As a side note, this might just be a me thing, but I distinguish between "complex" and "complicated". Certain things have an inherently complexity. Stripped to their essence, they're still going to have a lot of moving parts. It's just their nature. However, you can also add complication on top of something that makes it more complex than it needs to be to perform its function. Think "complication" in the watchmaker'…

Yeah, I was slightly sloppy about that, but also the distinction doesn't entirely help at this level because people get into vicious fights about whether a particular bit of complexity is really "necessary". E.g., lots of people argue that async Rust is unnecessary complication, either because you can just write all the state machines by hand (which is terrible for expressiveness, but do you really need expressivenes…

Oh, I hear ya. That makes perfect sense, and you're so right: my idea of a complex solution might be someone else's complication, and vice versa. I didn't mean to disagree with you, and surely not to correct you, because not everyone agrees on the distinction I make between the ideas.

I meant that more in the spirit of "oh, while we're talking about this, here are my thoughts on a tangentially related idea".

Re: Upcoming Rust language features for kernel development

#169

Post by Jweb_Guru » Thu, Oct 16, 2025, 6:51 PM UTC

gpm wrote: post #142

uecker wrote: post #141

Earlier quoted context omitted.

I don't think so. First, Rust did not come from nowhere, there were memory safe C variants before it that stayed closer to C. Second, I do not even believe that memory safety is that important that this trumps other considerations, e.g. the complexity of having two languages in the kernel (even if you ignore the complexity of Rust). Now, it is not my decision but Google's and other company's influence. But I still th…

> First, Rust did not come from nowhere, there were memory safe C variants before it that stayed closer to C. Can you give an example? One that remained a low level language, and remained ergonomic enough for practical use? > Second, I do not even believe that memory safety is that important that this trumps other considerations In your previous comment you stated "a memory safe C would be far more useful. It is sad…

> Can you give an example? One that remained a low level language, and remained ergonomic enough for practical use?

They can't, of course, because there was no such language. Some people for whatever reason struggle to acknowledge that (1) Rust was not just the synthesis of existing ideas (the borrow checker was novel, and aspects of its thread safety story like Send and Sync were also AFAIK not found in the literature), and (2) to the extent that it was the synthesis of existing ideas, a number of these were locked away in languages that were not even close to being ready for industry adoption. There was no other Rust alternative (that genuinely aimed to replace C++ for all use cases, not just supplement it) just on the horizon or something around the time of Rust 1.0's release. Pretty much all the oxygen in the room for developing such a language has gone to Rust for well over a decade now, and that's why it's in the Linux kernel and [insert your pet language here] is not.

BTW, this is also why people being are incentivized to figure out ways to solve complex cases like Rcu-projection through extensible mechanisms (like the generic field projection proposal) rather than ditching Rust as a language because it can't currently handle these ergonomically. The lack of alternatives to Rust is a big driving factor for people to find these abstractions. Conversely, having the weight of the Linux kernel behind these feature requests (instead of e.g. some random hobbyist) makes it far more likely for them to actually get into the language.

Re: Upcoming Rust language features for kernel development

#170

Post by mustache_kimono » Thu, Oct 16, 2025, 6:52 PM UTC

a-dub wrote: post #47

> The Rust for Linux project has been good for Rust i just decided do a good ol' 'find -name "*.rs"' in the kernel tree to get a sense for what all this is about. from what i can tell, there's just an api compatibility layer (found in /rust) and then a smattering of proof of concept drivers in tree that appear to just be simple rewrites of existing drivers (with the exception of the incomplete nvidia thing) that aren…

> redox is a pretty cool experimental piece of software that might be the os of the future, why not do it there?

Because people want to use Rust where they use C, right now? Whereas yours is a perfectly fine criticism, it ignores that people want the good stuff, everywhere, in the things they actually use every day. And since this is something the project lead wants to do, this doesn't seem to problem/live issue.