Upcoming Rust language features for kernel development

In my experience, C++ is a much more complicated language. The 8 ways to initialize something, the 5 types of values (xvalues etc.), inconsistent formatting conventions, inconsistent naming conventions, the rule of 5, exceptions, always remembering to check `this != other` when doing a move assignment operator, perfect forwarding, SFINAE, workarounds for not having a great equivalent to traits, etc. . Part of knowing the language is also knowing the conventions on top that are necessary in order to write it more safely and faster (if your move constructor is not noexcept it'll cause copies to occur when growing a vector of that object), and learning the many non-ideal competing ways that people do things, like error handling.

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 solutions—but the purpose of this particular feature is to make it easier to write code that uses reference-counted pointers and reduce how much stuff the programmer has to keep track of. It doesn't let you do anything you can't already do, it just makes it less clunky. So if people can't easily understand what it does, then that's bad.

I find that Rust is a language that feels insurmountable when you examine it from a distance but once you get your hands dirty it feels natural very quickly.

Case in point, my first read on lifetimes just left me confused. So I used Rc<> everywhere and made a perfectly functional program. Picking up lifetimes after mastering the basics made it a lot easier. Most people won't even need to care about lightweight clones.

It is much more complex than C, sure. But it's so much simpler than C++ and you won't find yourself digging through the reference, or standard, or whatever to understand the code you are writing. It's very close to the sweet spot of "not complex enough to make you bald, not simple enough to make your code complex" while also making correctness the default.

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 asking clippy to do it automatically via --fix). This is distinctly not a superpower c++ has and why the complexity of c++ keeps piling up with either no one using the new features or using them in unnecessarily complicated ways.

I don't think Rust is very complex. What you're doing is very complex. It's just that doing it in C/C++ lulls you into a false sense of security.

C++ is incredibly complicated. I mean there's a 278 page book just on initialization [1].

I have seen all sorts of bad multithreaded code that compilers have let someone write. It would've been much harder in Rust but Rust would've forced you to be correct. As an example, I've seen a pool of locks for message delivery where the locks are locked on one thread and unlocked on another. This would get deadlocked every now and again so every half second or so a separate process would just release all the locks.

[1]: https://leanpub.com/cppinitbook

> Looking at the rust rfc for the lightweight clones feature

while the Use trait (a better name is proposed [1]) is useful, but I don't see how the .use syntax adds any value over .clone()? If the compiler is able to perform those optimizations, it can also lint and ask the user to remove the unnecessary .clone()/change x.clone() to &x. IMO this is better than the compiler doing black magic.

[1]: https://smallcultfollowing.com/babysteps/blog/2025/10/07/the...

In my opinion, it's not just about the complexity of C++ vs Rust. It's how often the complexity (or anything else) can unpleasantly surprise you, and how serious the consequences of that surprise are.

It is definitely a complex language though I would argue probably much less so, on the whole, than C++.

The problem with C++'s complexity is that you have to remember all of it yourself and if you forget some of it... boom undefined behaviour and elusive runtime bugs!

Rust is definitely on the same order of magnitude of complexity, but you don't have to remember it all. Usually if you forget some complex rule and make a mistake, the compiler will tell you.

That's not true for unsafe Rust, but you rarely need unsafe Rust. Apart from FFI I have yet to use it at all and I've been writing Rust for years.

Async Rust is probably the closest it gets to C++'s "you didn't explicitly co_return in the context of a promise with no return_void? ok carry on but I'm going to crash sometimes! maybe just in release mode, on another OS".

A very interesting post about this issue.

https://smallcultfollowing.com/babysteps/blog/2025/10/07/the...

there is currently a lot of ongoing discussions about "easier light weight clones" not just in the context of the RFC but in general.

And from all the discussions I have seen this RFC is one of the less promising ones as it mixes up the concept of "implicitly doing an operation before moving something into a closure scope" and "light weight clones" in a confusing ambiguous way.

So I don't expect it to be accepted/implemented this way, but I expect something similar to happen.

Like for "light weight clones" use is a pretty bad name and new syntax isn't needed, if we start shortening a `.clone()` to `.use` because it saves 4 letters then we are doing something wrong. Similar if argue for it for niche optimization reasons instead of improving generic optimizations to have the same outcome we are doing something wrong IMHO.

And for the the scoping/closure aspect (i.e. a rust equivalent of C++ closures `[]` parts (e.g. [&x](){...}) then it also seems a bad solution. First it's a operation which relates to the closure scope not the call inside of it, so attaching it to the call inside of it isn't a grate idea. Especially given that you might have multiple places you pass a clone of x in and this leading to a lot of ambiguity not highlighted with any examples in the RFC. Secondly for this concept it isn't limited to "cheap clones" sometimes you have the same pattern for not-so-cheap clones (through it mainly matters for cheap clones). And lastly if we really add ways to define captures, why not allow defining captures.

Now sure if you have a good solution for more compact way to handle "not-copy but still cheap" sharing (cloning of handles/smart pointers) of values there it maybe could make sense to also allow it to happen implicitly outside of closure capture scope instead of the invocation scope. But I would argue it's an extension of an not yet existing handle/smart pointer ergonomic improvement and should be done after that improvement.

(yes, I'm aware they use `use` because it's already a keyword, but making a non-zero cost copy of a handle/smart pointer isn't exactly "use it" but more like "share it" :/)

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++.

As someone who’s dipped their toes in it, I’d say Rust is complicated in theory but not as complicated in practice. I said on a different topic that LLMs help a bit with suggestions and you can start with suboptimal code, improving it as you get more confident.

Obviously I’m not building anything production ready in it but it’s been useful for a few apps that I’d previously been using Python for.

Fwiw C++ has the exact same problem with moving/referencing into closures, see "Lambda capture" in https://en.cppreference.com/w/cpp/language/lambda.html.

It seems like Rust is being thorough. This is the way.

> Yet people seem to like making useful things in it so it must have gotten something right.

I'm not commenting on Rust, seriously! But I couldn't help to notice that this sentence is a non sequitur. Something right has been developed in PHP and Visual Basic, even in Javascript and Go; still, those developers who freely choose to use those abominations, they do deserve to be pointed at and made fun of.

The gpu driver for Apple silicon is Rust and the author stated it would have been much more difficult to implement in C. It isn't upstreamed yet.

""" Normally, when you write a brand new kernel driver as complicated as this one, trying to go from simple demo apps to a full desktop with multiple apps using the GPU concurrently ends up triggering all sorts of race conditions, memory leaks, use-after-free issues, and all kinds of badness.

But all that just… didn’t happen! I only had to fix a few logic bugs and one issue in the core of the memory management code, and then everything else just worked stably! Rust is truly magical! Its safety features mean that the design of the driver is guaranteed to be thread-safe and memory-safe as long as there are no issues in the few unsafe sections. It really guides you towards not just safe but good design. """

https://asahilinux.org/2022/11/tales-of-the-m1-gpu/

> the whole thing seems kinda cute but like, shouldn't this experiment in programming language co-development be taking place somewhere other than the source tree for the world's most important piece of software?

Torvalds seems to disagree with you.

> from what i can tell even the android binder rust rewrite is vestigial.

This is incorrect. The android binder rust rewrite is planned to wholly replace the current C implementation.

https://www.phoronix.com/news/Rust-Binder-For-Linux-6.18

And most of the big drivers written for Apple M-series hardware are written in Rust, those are not simple rewrites or proof of concepts.

> from what i can tell even the android binder rust rewrite is vestigial.

Vestigal how? The commit message in the version in Linus's tree (from commit eafedbc7c050c44744fbdf80bdf3315e860b7513 "rust_binder: add Rust Binder driver") makes it seem rather more complete:

> Rust binder passes all tests that validate the correctness of Binder in the Android Open Source Project. We can boot a device, and run a variety of apps and functionality without issues. We have performed this both on the Cuttlefish Android emulator device, and on a Pixel 6 Pro.

> As for feature parity, Rust binder currently implements all features that C binder supports, with the exception of some debugging facilities. The missing debugging facilities will be added before we submit the Rust implementation upstream.

----

> shouldn't this experiment in programming language co-development be taking place somewhere other than the source tree for the world's most important piece of software?

Rust for Linux did start as an out-of-tree project. The thing is that no matter how much work you do out of tree if you're serious about trying integration out you'll have to pull in experimental support at some point - which is more or less what is happening now.

Before you can have complex drivers you need the interface layer that the drivers are built on. The RfL project works on that, upstreaming more infrastructure work until there's enough to submit a complex driver. Redhat is working on nova, asahi on the apple GPU, collabora is working on one for ARM Mali. If 3 GPU drivers don't count as complex, real drivers then what does?

"Experiment" is a misnomer. Rust has been around long enough and demonstrated more than enough real advantages in writing reliable code that we know it's what we want to be doing.

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.

It's hard to view the relatively small scope of existing Rust code in the kernel at the present time as an indictment of the utility of Rust being used in the kernel when there are major kernel maintainers who have publicly stated that they have been doing everything in their power to block any amount of Rust code from getting merged into any part of the codebase.

> 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.

> shouldn't this experiment in programming language co-development be taking place somewhere other than the source tree for the world's most important piece of software?

The language co-development isn't unique to Rust. There are plenty of features in GCC and Clang that exist specifically for Kernel usage too.

> there's just an api compatibility layer (found in /rust)

Even figuring out what exactly the Linux kernel API safety rules are is a huge task, much less encoding them in a computer-readable form.

The code there is not about C<->Rust FFI. It's about encoding Linux kernel API properties into a safe Rust API.

The uncertainty of the calling/ordering rules is exactly why kernel C has been hard to write. For VFS locking rules, you pretty much have to simulate Al Viro's brain and replay his whole life experience...

> 'find -name ".rs"'

Since this is a Git repo, I'd go with `git ls-files '.rs'`.

> shouldn’t this be taking place somewhere else

That’s an interesting idea. You should let this guy know you disagree with his technical decision -> torvalds@linux-foundation.org

I'm probably misunderstanding the complexity of the problem, but wouldn't this be solvable by just defining the right calling convention?

"Any structures larger than x, or any structures marked with a marker type, are returned by the caller providing an outref to a buffer with correct size, and the callee directly writes the structure into that buffer."

Then you could just write normal code like

    fn initialize() -> A { 
    // the initialization code 
    }

and it would just work? And it would reduce unnecessary copies in a lot of other situations too? Given how much work has been put into this issue, and how much less convenient the proposed solutions are, I feel like I must be missing something.

Why make this a behind-the-scene optimization instead of just introducing `new`? That would make things much more clear for everyone.

How does "coalesced heap construction" or "coalesced heap allocation"?

C++ uses the term elision for these kinds of semantics.

It's trivial to implement an async runtime in the kernel. The kernel's workqueue is already essentially a runtime.

I'm not sure if you're joking, but if not this is a fundamental misunderstanding of how Rust (and C) are used in the kernel.

Much like how you don't have the C stdlib when writing kernel code, Rust is used with the no_std option. You do not use cargo and do not have access to crates.

You'd likely have to rewrite half of tokio to use kernel level abstractions for things like sockets and everything else that interacts with the OS.