That is so good to hear. I feel Rust support came a long way in the past two years and you can do a functional Rust kernel module now with almost no boilerplate.
Removing the "experimental" tag is certainly a milestone to celebrate.
I'm looking forward to distros shipping a default kernel with Rust support enabled. That, to me, will be the real point of no return, where Rust is so prevalent that there will be no going back to a C only Linux.
A few distros already do that. Of the top of my head, both NixOS and Arch enable the QR code kernel panic screen, which is written in Rust. Granted, those are rather bleeding edge, but I know a few more traditional distros have that enabled (I _think_ fedora has it? But not sure).
> I'm looking forward to distros shipping a default kernel with Rust support enabled
What does this mean? The kernel has no specific support for Rust userspace -- the syscall API does not suddenly change because some parts of the kernel are compiled with rustc.
wasn't there like a drive by maintainer rejection of something rust related that kind of disrupted the asahi project ? i can't say i followed the developments much but i do recall it being some of that classic linux kernel on broadway theater. i also wonder if that was a first domino falling of sorts for asahi, i legitimately can't tell if that project lives on anymore
<< Alex Gaynor recently announced he is formally stepping down as one of the maintainers of the Rust for Linux kernel code with the removal patch now queued for merging in Linux 6.19. Alex Gaynor was one of the original developers to experiment with Rust code for Linux kernel modules. He's drifted away from Rust Linux kernel development for a while due to lack of time and is now formally stepping down as a listed co-maintainer of the Rust code. After Wedson Almeida Filho stepped down last year as a Rust co-maintainer, this now leaves Rust For Linux project leader Miguel Ojeda as the sole official maintainer of the code while there are several Rust code reviewers. >>
I believe the removal of the "experimental" nomenclature is just an indication that Rust is "here to stay" in the kernel (which essentially means that developers can have confidence investing in writing Rust based drivers).
The overall rules haven't changed.
Strictly speaking they've always been obligated to not break the Rust code, but the R4L developers have agreed to fix it on some subsystems behalf IIRC so Rust can be broken in the individual subsystem trees. But I think it's been the case all along that you can't send it to Linus if it breaks the Rust build, and you probably shouldn't send it to linux-next either.
No, Rust is in the kernel for driver subsystems. Core linux parts can't be written in Rust yet for the problem you mention. But new drivers *can* be written in Rust
What does this practically mean for Linux? Will core parts of it depend on Rust? How closely linked are drivers?
Rust in Linux always worried me because there is currently only one stable backend (LLVM) and only one compiler implementation that doesn't yet have a spec. I like that you can at least compile Linux with Clang and GCC, but there aren't even two options for Rust right now.
@dang title has been changed to "The (successful) end of the kernel Rust experiment", since there were complaints in the articles comments from the committee members that that was a sensationalization of what actually happened.
Unsuccessful experiments have no end unless motivation to keep trying runs out — but Rust seems to have no end to motivation behind it. Besides, if it were to ever reach the point of there being no remaining motivation, there would be no remaining motivation for those who have given up to announce that they have given up, so we'd never see the headline to begin with.
Why? New things are less stable, immature and require a lot of effort to understand.
Don't get me wrong, rust in the kernel is good, because the memory safety and expressiveness it brings makes it worth it DESPITE the huge effort required to introduce it. But I disagree that new things are inherently good.
Hmm seeing as this looks to be the path forward as far as inkernel Linux drivers are concerned , adnfor BSDs like FreeBSD that port said drivers to their own kernel.
Are we going to see the same oxidation of the BSD's or resistance and bifurcation.
I need to check the rust parts of the kernel, I presume there is significant amounts of unsafe. Is unsafe Rust a bit better nowadays? I remember a couple of years ago people complained that unsafe is really hard to write and very "un-ergonomic".
The idea is that most of the unsafe code to interact with the C API of the kernel is abstracted in the kernel crate, and the drivers themselves should use very little amount of unsafe code, if any.
unsafe {
// this is normal Rust code, you can write as much of it as you like!
// (and you can bend some crucial safety rules)
// but try to limit and document what you put inside an unsafe block.
// then wrap it in a safe interface so no one has to look at it again
}
I don't think unsafe Rust has gotten any easier to write, but I'd also be surprised if there was much unsafe except in the low-level stuff (hard to write Vec without unsafe), and to interface with C which is actually not hard to write.
Mostly Rust has been used for drivers so far. Here's the first Rust driver I found:
Other platforms don't have a leader that hates C++, and then accepts a language that is also quite complex, even has two macro systems of Lisp like wizardy, see Serde.
OSes have been being written with C++ on the kernel, since the late 1990's, and AI is being powered by hardware (CUDA) that was designed specifically to accomodate C++ memory model.
Also Rust compiler depends on a compiler framework written in C++, without it there is no Rust compiler, and apparently they are in no hurry to bootstrap it.
C++ devs don’t care what the Linux kernel’s written in.
But I did see an interesting comment from another user here which also reflects my feelings: Rust is pushed aggressively with different pressure tactics. Another comment pointed out that Rust is not about Rust programmers writing more Rust, but “Just like a religion it is about what other people should do.”.
I’ve been reading about this Rust-in-the-kernel topic since the beginning, without getting involved. One thing that struck me is the obvious militant approach of the rustafarians, criticizing existing maintainers (particularly Ts’o and other objectors), implying they’re preventing progress or out of touch.
The story feels more like a hostile takeover attempt than technology.
I also think that many C or C++ programmers don’t bother posting in this topics, so they’re at least partially echo chambers.
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?
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, and the pointer size type are all the same type, which is not the case for a couple of architectures; it's also the case that things like segmented pointers don't really work in Rust (of course, they barely work in C, but barely is more than nothing).
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.
There are certain styles of programming and data structure implementations that end up requiring you to fight Rust at almost every step. Things like intrusive data structures, pointer manipulation and so on. Famously there is an entire book online on how to write a performant linked list in idiomatic Rust - something that is considered straightforward in C.
For these cases you could always use Zig instead of C
Before we ask if almost all things old will be rewritten in Rust, we should ask if almost all things new are being written in Rust or other memory-safe languages?
Obviously not. When will that happen? 15 years? Maybe it's generational: How long before developers 'born' into to memory-safe languages as serious choices will be substantially in charge of software development?
Yes it does, alongside C++, Rust isn't available everywhere.
There are industry standards based in C, or C++, and I doubt they will be adopting Rust any time soon.
POSIX (which does require a C compiler for certification), OpenGL, OpenCL, SYSCL, Aparavi, Vulkan, DirectX, LibGNM(X), NVN, CUDA, LLVM, GCC, Unreal, Godot, Unity,...
Then plenty of OSes like the Apple ecosystem, among many other RTOS and commercial endevours for embedded.
Also the official Rust compiler isn't fully bootstraped yet, thus it depends on C++ tooling for its very existence.
Which is why efforts to make C and C++ safer are also much welcomed, plenty of code out there is never going to be RIR, and there are domains where Rust will be a runner up for several decades.
It’s available on more obscure platforms than Rust, and more people are familiar with it.
I wouldn’t say it’s inevitable that everything will be rewritten in Rust, at the very least this will this decades. C has been with us for more than half a century and is the foundation of pretty much everything, it will take a long time to migrate all that.
More likely is that they will live next to each other for a very, very long time.
Rust still compiles into bigger binary sizes than C, by a small amount. Although it’s such a complex thing depending on your code that it really depends case-by-case, and you can get pretty close. On embedded systems with small amounts of ram (think on the order of 64kbytes), a few extra kb still hurts a lot.
Apple handled this problem by adding memory safety to C (Firebloom). It seems unlikely they would throw away that investment and move to Rust. I’m sure lots of other companies don’t want to throw away their existing code, and when they write new code there will always be a desire to draw on prior art.
It's a bit like asking if there is any significant advantage to ICE motors over electric motors. They both have advantages and disadvantages. Every person who uses one or the other, will tell you about their own use case, and why nobody could possibly need to use the alternative.
There's already applications out there for the "old thing" that need to be maintained, and they're way too old for anyone to bother with re-creating it with the "new thing". And the "old thing" has some advantages the "new thing" doesn't have. So some very specific applications will keep using the "old thing". Other applications will use the "new thing" as it is convenient.
To answer your second question, nothing is inevitable, except death, taxes, and the obsolescence of machines. Rust is the new kid on the block now, but in 20 years, everybody will be rewriting all the Rust software in something else (if we even have source code in the future; anyone you know read machine code or punch cards?). C'est la vie.
I think it'll be less like telegram lines- which were replaced fully for a major upgrade in functionality, and more like rail lines- which were standardized and ubiquitous, still hold some benefit but mainly only exist in areas people don't venture nearly as much.
Shitloads of already existing libraries. For example I'm not going to start using it for Arduino-y things until all the peripherals I want have drivers written in Rust.
Rust has a nice compiler-provided static analyzer using annotation to do life time analysis and borrow checking. I believe borrow checking to be a local optima trap when it comes to static analysis and finds it often more annoying to use than I would like but I won't argue it's miles better than nothing.
C has better static analysers available. They can use annotations too. Still, all of that is optional when it's part of Rust core language. You know that Rust code has been successfully analysed. Most C code won't give you this. But if it's your code base, you can reach this point in C too.
C also has a fully proven and certified compiler. That might be a requirement if you work in some niche safety critical applications. Rust has no equivalent there.
The discussion is more interesting when you look at other languages. Ada/Spark is for me ahead of Rust both in term of features and user experience regarding the core language.
Rust currently still have what I consider significant flaws: a very slow compiler, no standard, support for a limited number of architectures (it's growing), it's less stable that I consider it should be given its age, and most Rust code tends to use more small libraries than I would personaly like.
Rust is very trendy however and I don't mean that in a bad way. That gives it a lot of leverage. I doubt we will ever see Ada in the kernel but here we are with Rust.
you can look at rust sources of real system programs like framekernel or such things. uefi-rs etc.
there u can likely explore well the boundaries where rust does and does not work.
people have all kind of opinions. mine is this:
if you need unsafe peppered around, the only thing rust offers is being very unergonomic. its hard to write and hard to debug for no reason. Writing memory-safe C code is easy. The problems rust solves arent bad, just solved in a way thats way more complicated than writing same (safe) C code.
a language is not unsafe. you can write perfectly shit code in rust. and you can write perfectly safe code in C.
people need to stop calling a language safe and then reimplementing other peoples hard work in a bad way creating whole new vulnerabilities.
For my hobby code, I'm not going to start writing Rust anytime soon. My code is safe enough and I like C as it is. I don't write software for martian rovers, and for ordinary tasks, C is more ergonomic than Rust, especially for embedded tasks.
For my work code, it all comes down to SDKs and stuff. For example I'm going to write firmware for Nordic ARM chip. Nordic SDK uses C, so I'm not going to jump through infinite number of hoops and incomplete rust ports, I'll just use official SDK and C. If it would be the opposite, I would be using Rust, but I don't think that would happen in the next 10 years.
Just like C++ never killed C, despite being perfect replacement for it, I don't believe that Rust would kill C, or C++, because it's even less convenient replacement. It'll dilute the market, for sure.
A lot of C's popularity is with how standard and simple it is. I doubt Rust will be the safe language of the future, simply because of its complexity. The true future of "safe" software is already here, JavaScript.
There will be small niches leftover:
* Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers.
* OS / Kernel - Nearly all of the relevant code is unsafe. There aren't many real benefits. It will happen anyways due to grant funding requirements. This will take decades, maybe a century. A better alternative would be a verified kernel with formal methods and a Linux compatibility layer, but that is pie in the sky.
* Game Engines - Rust screwed up its standard library by not putting custom allocation at the center of it. Until we get a Rust version of the EASTL, adoption will be slow at best.
* High Frequency Traders - They would care about the standard library except they are moving on from C++ to VHDL for their time-sensitive stuff. I would bet they move to a garbage-collected language for everything else, either Java or Go.
* Browsers - Despite being born in a browser, Rust is unlikely to make any inroads. Mozilla lost their ability to make effective change and already killed their Rust project once. Google has probably the largest C++ codebase in the world. Migrating to Rust would be so expensive that the board would squash it.
* High-Throughput Services - This is where I see the bulk of Rust adoption. I would be surprised if major rewrites aren't already underway.
This title is moderately clickbait-y and comes with a subtle implication that Rust might be getting removed from the kernel. IMO it should be changed to "Rust in the kernel is no longer experimental"
I absolutely understand the sentiment, but LWN is a second-to-none publication that on this rare occasion couldn't resist the joke, and also largely plays to an audience who will immediately understand that it's tongue-in-cheek.
Speaking as a subscriber of about two decades who perhaps wouldn't have a career without the enormous amount of high-quality education provided by LWN content, or at least a far lesser one: Let's forgive.
It’s a bit clickbait-y, but the article is short, to the point, and frankly satisfying. If there is such a thing as good clickbait, then this might be it. Impressive work!
> same Mike in an org wide email: thank you all for your support. Starting next week I will no longer be a developer here. I thank my manager blah blah... I will be starting my dream role as Architect and I hope to achieve success.
> Mike's colleagues: Aww.. We'll miss you.
> Mike's manager: Is this your one week's notice? Did you take up an architect job elsewhere immediately after I promoted you to architect ?!
you're joking because of the other frontpage story with Gemini 3 hallucinating hacker news 10 years in the future, but still lets keep the hallucinations to that page.
The Linux kernel is already very complex, and I expect that replacing much or all of it with Rust code will be good for making it more tractable to understand. Because you can represent complex states with more sophisticated types than in C, if nothing else.
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)
> 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)
It's trivial to install a specific version of the toolchain though.
It's not ideal, but at least most of these are only used in the `kernel` crate, i.e. if there's a breaking change to these features it should be fixable without widespread changes.
Why do Rust developers create so much drama everywhere? "Rewrite everything to Rust", "Rust is better than X" in all threads related to other languages, "how do you know it's safe if you don't use Holy Glorious Rust".
I'm genuinely not trolling, and Rust is okay, but only Rust acolytes exhibit this behaviour.
BSD development mostly works through the classic approach of pretending that if you write C code and then stare at it really really hard it'll be correct.
I'm not actually sure if they've gotten as far as having unit tests.
(OpenBSD adds the additional step of adding a zillion security mitigations that were revealed to them in a dream and don't actually do anything.)
I never used linux because it was built using C++. Never have I cared what language the product was built it. The Rust community however wants you to use a product just because it's implemented in Rust, or atleast as one of the selling points. For that reason I decided to avoid any product that advertises using Rust as a selling point, as much as I can. Was planning to switch from Mac to a Linux machine, not anymore, I'm happily upgrading my mac.
It's an optional tool that can be used to implement drivers now, not forced. If you don't like the idea of another language being supported for implementing a subset of kernel modules, I don't think you wouldn't enjoyed having a Linux machine anyways.
They had me in the first half of the article, not gonna lie. I thought they resigned because Rust was so complicated and unsuitable, but it's the opposite
Rust in the kernel feels like a red herring. For fault tolerance and security, wouldn’t it be a superior solution to migrate Linux to a microkernel architecture? That way, drivers and various other components could be isolated in sandboxes.
I am not a system programmer but, from my understanding, Torvalds has expressed strong opinions about microkernels over a long period of time. The concept looks cleaner on paper but the complexity simply outweighs all the potential benefits. The debate, from what I have followed, expressed similar themes as monolithic vs microservices in the wider software development arena.
Microkernel architecture doesn't magically eliminate bugs, it just replaces a subset of kernel panics with app crashes. Bugs will be there, they will keep impacting users, they will need to be fixed.
This is great because it means someday (possibly soon) Linux development will slowly grind to a halt and become unmaintainable, so we can start from scratch and write a new kernel.
That is so good to hear. I feel Rust support came a long way in the past two years and you can do a functional Rust kernel module now with almost no boilerplate.
Removing the "experimental" tag is certainly a milestone to celebrate.
I'm looking forward to distros shipping a default kernel with Rust support enabled. That, to me, will be the real point of no return, where Rust is so prevalent that there will be no going back to a C only Linux.
A few distros already do that. Of the top of my head, both NixOS and Arch enable the QR code kernel panic screen, which is written in Rust. Granted, those are rather bleeding edge, but I know a few more traditional distros have that enabled (I _think_ fedora has it? But not sure).
> I'm looking forward to distros shipping a default kernel with Rust support enabled
What does this mean? The kernel has no specific support for Rust userspace -- the syscall API does not suddenly change because some parts of the kernel are compiled with rustc.
Will it be possible until Rust gets full GCC support, with all its platforms?
I think Fedora 43 is compiled with CONFIG_RUST=y.
After all the resistance to Rust in the Linux Kernel, it's finally official. Kudos to the Linux Rust team!
wasn't there like a drive by maintainer rejection of something rust related that kind of disrupted the asahi project ? i can't say i followed the developments much but i do recall it being some of that classic linux kernel on broadway theater. i also wonder if that was a first domino falling of sorts for asahi, i legitimately can't tell if that project lives on anymore
https://www.phoronix.com/news/Alex-Gaynor-Rust-Maintainer
Does the removal of “experimental” now mean that all maintainers are now obligated to not break Rust code?
I believe the removal of the "experimental" nomenclature is just an indication that Rust is "here to stay" in the kernel (which essentially means that developers can have confidence investing in writing Rust based drivers).
The overall rules haven't changed.
Strictly speaking they've always been obligated to not break the Rust code, but the R4L developers have agreed to fix it on some subsystems behalf IIRC so Rust can be broken in the individual subsystem trees. But I think it's been the case all along that you can't send it to Linus if it breaks the Rust build, and you probably shouldn't send it to linux-next either.
Yeah I was wondering about that one angry bearded guy in that movie. He will be very upset.
Is rust code part of user space?
No maintainer is obligated to not break any part of Linux other than the user space API, there are no stable in-kernel APIs
Does this mean that all architectures that Linux supports but Rust doesn't are straight in the bin?
No, Rust is in the kernel for driver subsystems. Core linux parts can't be written in Rust yet for the problem you mention. But new drivers *can* be written in Rust
Which ones would that be?
Yes. Cooked.
What does this practically mean for Linux? Will core parts of it depend on Rust? How closely linked are drivers?
Rust in Linux always worried me because there is currently only one stable backend (LLVM) and only one compiler implementation that doesn't yet have a spec. I like that you can at least compile Linux with Clang and GCC, but there aren't even two options for Rust right now.
@dang title has been changed to "The (successful) end of the kernel Rust experiment", since there were complaints in the articles comments from the committee members that that was a sensationalization of what actually happened.
Thanks! This is cromulent.
From https://news.ycombinator.com/newsguidelines.html: "Please use the original title, unless it is misleading or linkbait". Therefore: when misleading please edit.
Isn't successful already implied?
Unsuccessful experiments have no end unless motivation to keep trying runs out — but Rust seems to have no end to motivation behind it. Besides, if it were to ever reach the point of there being no remaining motivation, there would be no remaining motivation for those who have given up to announce that they have given up, so we'd never see the headline to begin with.
"Linux kernel devs tried Rust in the kernel -- you won't BELIEVE the reaction!"
This seems big. Is this big?
It's a big dependency added alright.
Yup.
Happy to hear. We should embrace new things.
Great. Python in the kernel!
Why? New things are less stable, immature and require a lot of effort to understand.
Don't get me wrong, rust in the kernel is good, because the memory safety and expressiveness it brings makes it worth it DESPITE the huge effort required to introduce it. But I disagree that new things are inherently good.
So what is written in Rust so far therein?
> Linux's DRM Panic "Screen of Death"
> "There is no particular reason to do it in rust, I just wanted to learn rust, and see if it can work in the kernel."
https://www.phoronix.com/news/Linux-DRM-Panic-QR-Codes
Mostly GPU drivers
Hmm seeing as this looks to be the path forward as far as inkernel Linux drivers are concerned , adnfor BSDs like FreeBSD that port said drivers to their own kernel. Are we going to see the same oxidation of the BSD's or resistance and bifurcation.
I need to check the rust parts of the kernel, I presume there is significant amounts of unsafe. Is unsafe Rust a bit better nowadays? I remember a couple of years ago people complained that unsafe is really hard to write and very "un-ergonomic".
The idea is that most of the unsafe code to interact with the C API of the kernel is abstracted in the kernel crate, and the drivers themselves should use very little amount of unsafe code, if any.
Wouldn't that be by design? If it isn't pleasant, people will avoid using it if they can.
(but as others pointed out, unsafe should only be used at the 'edges', the vast majority should never need to use unsafe)
I don't think unsafe Rust has gotten any easier to write, but I'd also be surprised if there was much unsafe except in the low-level stuff (hard to write Vec without unsafe), and to interface with C which is actually not hard to write.
Mostly Rust has been used for drivers so far. Here's the first Rust driver I found:
https://github.com/torvalds/linux/blob/2137cb863b80187103151...
It has one trivial use of `unsafe` - to support Send & Sync for a type - and that is apparently temporary. Everything else uses safe APIs.
I'm mostly interested in being able to interact with the vfs and build a 9p rust client (in addition to the current v9fs) to support my 9p server [0].
Does anyone know what's the current state / what is the current timeline for something like this to be feasible?
[0] https://github.com/Barre/ZeroFS
If you just want to play https://github.com/cberner/fuser
The title sounded worse than it is.
C++ devs are spinning in their graves now.
Why should they?
Other platforms don't have a leader that hates C++, and then accepts a language that is also quite complex, even has two macro systems of Lisp like wizardy, see Serde.
OSes have been being written with C++ on the kernel, since the late 1990's, and AI is being powered by hardware (CUDA) that was designed specifically to accomodate C++ memory model.
Also Rust compiler depends on a compiler framework written in C++, without it there is no Rust compiler, and apparently they are in no hurry to bootstrap it.
Or installing Haiku!
The C++ that have the humility to realize are using Rust.
The kernel is mostly C code, not C++.
C++ devs don’t care what the Linux kernel’s written in.
But I did see an interesting comment from another user here which also reflects my feelings: Rust is pushed aggressively with different pressure tactics. Another comment pointed out that Rust is not about Rust programmers writing more Rust, but “Just like a religion it is about what other people should do.”.
I’ve been reading about this Rust-in-the-kernel topic since the beginning, without getting involved. One thing that struck me is the obvious militant approach of the rustafarians, criticizing existing maintainers (particularly Ts’o and other objectors), implying they’re preventing progress or out of touch.
The story feels more like a hostile takeover attempt than technology. I also think that many C or C++ programmers don’t bother posting in this topics, so they’re at least partially echo chambers.
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?
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, and the pointer size type are all the same type, which is not the case for a couple of architectures; it's also the case that things like segmented pointers don't really work in Rust (of course, they barely work in C, but barely is more than nothing).
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.
There are certain styles of programming and data structure implementations that end up requiring you to fight Rust at almost every step. Things like intrusive data structures, pointer manipulation and so on. Famously there is an entire book online on how to write a performant linked list in idiomatic Rust - something that is considered straightforward in C.
For these cases you could always use Zig instead of C
C is fun to write. I can write Rust, but I prefer writing C. I prefer compiling C, I prefer debugging C. I prefer C.
It's a bit like asking with the new mustang on the market, with airbags and traction control, why would you ever want to drive a classic mustang?
Before we ask if almost all things old will be rewritten in Rust, we should ask if almost all things new are being written in Rust or other memory-safe languages?
Obviously not. When will that happen? 15 years? Maybe it's generational: How long before developers 'born' into to memory-safe languages as serious choices will be substantially in charge of software development?
Yes it does, alongside C++, Rust isn't available everywhere.
There are industry standards based in C, or C++, and I doubt they will be adopting Rust any time soon.
POSIX (which does require a C compiler for certification), OpenGL, OpenCL, SYSCL, Aparavi, Vulkan, DirectX, LibGNM(X), NVN, CUDA, LLVM, GCC, Unreal, Godot, Unity,...
Then plenty of OSes like the Apple ecosystem, among many other RTOS and commercial endevours for embedded.
Also the official Rust compiler isn't fully bootstraped yet, thus it depends on C++ tooling for its very existence.
Which is why efforts to make C and C++ safer are also much welcomed, plenty of code out there is never going to be RIR, and there are domains where Rust will be a runner up for several decades.
It’s available on more obscure platforms than Rust, and more people are familiar with it.
I wouldn’t say it’s inevitable that everything will be rewritten in Rust, at the very least this will this decades. C has been with us for more than half a century and is the foundation of pretty much everything, it will take a long time to migrate all that.
More likely is that they will live next to each other for a very, very long time.
Rust still compiles into bigger binary sizes than C, by a small amount. Although it’s such a complex thing depending on your code that it really depends case-by-case, and you can get pretty close. On embedded systems with small amounts of ram (think on the order of 64kbytes), a few extra kb still hurts a lot.
Apple handled this problem by adding memory safety to C (Firebloom). It seems unlikely they would throw away that investment and move to Rust. I’m sure lots of other companies don’t want to throw away their existing code, and when they write new code there will always be a desire to draw on prior art.
A C compiler is easier to bootstrap than a Rust compiler.
It's a bit like asking if there is any significant advantage to ICE motors over electric motors. They both have advantages and disadvantages. Every person who uses one or the other, will tell you about their own use case, and why nobody could possibly need to use the alternative.
There's already applications out there for the "old thing" that need to be maintained, and they're way too old for anyone to bother with re-creating it with the "new thing". And the "old thing" has some advantages the "new thing" doesn't have. So some very specific applications will keep using the "old thing". Other applications will use the "new thing" as it is convenient.
To answer your second question, nothing is inevitable, except death, taxes, and the obsolescence of machines. Rust is the new kid on the block now, but in 20 years, everybody will be rewriting all the Rust software in something else (if we even have source code in the future; anyone you know read machine code or punch cards?). C'est la vie.
I think it'll be less like telegram lines- which were replaced fully for a major upgrade in functionality, and more like rail lines- which were standardized and ubiquitous, still hold some benefit but mainly only exist in areas people don't venture nearly as much.
Shitloads of already existing libraries. For example I'm not going to start using it for Arduino-y things until all the peripherals I want have drivers written in Rust.
Ubiquity is still a big one. There's many, many places where C exists that Rust has not reached yet.
Depends of what you do.
Rust has a nice compiler-provided static analyzer using annotation to do life time analysis and borrow checking. I believe borrow checking to be a local optima trap when it comes to static analysis and finds it often more annoying to use than I would like but I won't argue it's miles better than nothing.
C has better static analysers available. They can use annotations too. Still, all of that is optional when it's part of Rust core language. You know that Rust code has been successfully analysed. Most C code won't give you this. But if it's your code base, you can reach this point in C too.
C also has a fully proven and certified compiler. That might be a requirement if you work in some niche safety critical applications. Rust has no equivalent there.
The discussion is more interesting when you look at other languages. Ada/Spark is for me ahead of Rust both in term of features and user experience regarding the core language.
Rust currently still have what I consider significant flaws: a very slow compiler, no standard, support for a limited number of architectures (it's growing), it's less stable that I consider it should be given its age, and most Rust code tends to use more small libraries than I would personaly like.
Rust is very trendy however and I don't mean that in a bad way. That gives it a lot of leverage. I doubt we will ever see Ada in the kernel but here we are with Rust.
You mean safer languages like Fil-C.
>does C hold any significant advantage over Rust
Yes, it's lots of fun. rust is Boring.
If I want to implement something and have fun doing it, I ll always do it in C.
you can look at rust sources of real system programs like framekernel or such things. uefi-rs etc.
there u can likely explore well the boundaries where rust does and does not work.
people have all kind of opinions. mine is this:
if you need unsafe peppered around, the only thing rust offers is being very unergonomic. its hard to write and hard to debug for no reason. Writing memory-safe C code is easy. The problems rust solves arent bad, just solved in a way thats way more complicated than writing same (safe) C code.
a language is not unsafe. you can write perfectly shit code in rust. and you can write perfectly safe code in C.
people need to stop calling a language safe and then reimplementing other peoples hard work in a bad way creating whole new vulnerabilities.
For my hobby code, I'm not going to start writing Rust anytime soon. My code is safe enough and I like C as it is. I don't write software for martian rovers, and for ordinary tasks, C is more ergonomic than Rust, especially for embedded tasks.
For my work code, it all comes down to SDKs and stuff. For example I'm going to write firmware for Nordic ARM chip. Nordic SDK uses C, so I'm not going to jump through infinite number of hoops and incomplete rust ports, I'll just use official SDK and C. If it would be the opposite, I would be using Rust, but I don't think that would happen in the next 10 years.
Just like C++ never killed C, despite being perfect replacement for it, I don't believe that Rust would kill C, or C++, because it's even less convenient replacement. It'll dilute the market, for sure.
A lot of C's popularity is with how standard and simple it is. I doubt Rust will be the safe language of the future, simply because of its complexity. The true future of "safe" software is already here, JavaScript.
There will be small niches leftover:
* Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers.
* OS / Kernel - Nearly all of the relevant code is unsafe. There aren't many real benefits. It will happen anyways due to grant funding requirements. This will take decades, maybe a century. A better alternative would be a verified kernel with formal methods and a Linux compatibility layer, but that is pie in the sky.
* Game Engines - Rust screwed up its standard library by not putting custom allocation at the center of it. Until we get a Rust version of the EASTL, adoption will be slow at best.
* High Frequency Traders - They would care about the standard library except they are moving on from C++ to VHDL for their time-sensitive stuff. I would bet they move to a garbage-collected language for everything else, either Java or Go.
* Browsers - Despite being born in a browser, Rust is unlikely to make any inroads. Mozilla lost their ability to make effective change and already killed their Rust project once. Google has probably the largest C++ codebase in the world. Migrating to Rust would be so expensive that the board would squash it.
* High-Throughput Services - This is where I see the bulk of Rust adoption. I would be surprised if major rewrites aren't already underway.
This title is moderately clickbait-y and comes with a subtle implication that Rust might be getting removed from the kernel. IMO it should be changed to "Rust in the kernel is no longer experimental"
I absolutely understand the sentiment, but LWN is a second-to-none publication that on this rare occasion couldn't resist the joke, and also largely plays to an audience who will immediately understand that it's tongue-in-cheek.
Speaking as a subscriber of about two decades who perhaps wouldn't have a career without the enormous amount of high-quality education provided by LWN content, or at least a far lesser one: Let's forgive.
If it was being removed the title would be "An update on rust in the kernel"
I think on HN, people generally want the submission's title to match the page's title.
(I do agree it's clickbait-y though)
It’s a bit clickbait-y, but the article is short, to the point, and frankly satisfying. If there is such a thing as good clickbait, then this might be it. Impressive work!
i agree and this matches the authors intent: https://lwn.net/Articles/1049840/
He didn't mean to! That said, the headline did make me look.
I'm having deja Vu. Was there another quite similar headline here a few weeks or so ago?
Seems you do not understand the concept of fun. You can learn that, makes your life easier.
> same Mike in an org wide email: thank you all for your support. Starting next week I will no longer be a developer here. I thank my manager blah blah... I will be starting my dream role as Architect and I hope to achieve success.
> Mike's colleagues: Aww.. We'll miss you.
> Mike's manager: Is this your one week's notice? Did you take up an architect job elsewhere immediately after I promoted you to architect ?!
I was confused but then noticed the actual headline of the submitted page: "The end of the kernel Rust experiment"
I legit thought that rust is being removed.
Good meme!
really? I recently read that "A 100% Rust kernel is now upstream in Linux 7.4"
That was from an AI hallucinating HN 10 years from now: https://news.ycombinator.com/item?id=46205632
I see that my ability to communicate things obliquely as is my habit and the hallmark of my personal style is doing as well as ever on HN.
I was wondering if anybody "ate the onion" from the other day...
you're joking because of the other frontpage story with Gemini 3 hallucinating hacker news 10 years in the future, but still lets keep the hallucinations to that page.
Safety is good.
Unless it means sacrificing freedom.
That is why most of the world has not been using c/c++ for decades.
Oh dear can you imagine the crushing complexity of a future Rust kernel.
By most accounts the Rust4Linux project has made the kernel less complex by forcing some technical debt to be addressed and bad APIs to be improved.
The Linux kernel is already very complex, and I expect that replacing much or all of it with Rust code will be good for making it more tractable to understand. Because you can represent complex states with more sophisticated types than in C, if nothing else.
Complexity of Rust is just codifying existing complexity.
Do you have any quantitative measures to prove there would be an increase in complexity?
There’s one already — they seem to be doing decently well.
https://www.redox-os.org/
That's what you get with slippery slopes.
Rust in the kernel is a self-fulfilling prophecy.
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.
> 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)
It's trivial to install a specific version of the toolchain though.
luckily downloading a specific nightly version is only a single rustup command
What if I told you… there was a simple, constant environment variable you could set to make the stable compiler forget it isn’t a nightly?
It's not ideal, but at least most of these are only used in the `kernel` crate, i.e. if there's a breaking change to these features it should be fixable without widespread changes.
Can you please share more details about this?
And we're cooked.
By the way, M$$$ has already making the transition of its driver writing in Rust
https://github.com/microsoft/windows-drivers-rs
maybe this will be good for the rest of the kernels, IllumOS/HaikuOS/ReactOS.
maybe
Why do Rust developers create so much drama everywhere? "Rewrite everything to Rust", "Rust is better than X" in all threads related to other languages, "how do you know it's safe if you don't use Holy Glorious Rust".
I'm genuinely not trolling, and Rust is okay, but only Rust acolytes exhibit this behaviour.
I guess it's time to finally try FreeBSD.
Why? Are you allergic to running rust code? You know, you can’t actually tell when you execute a binary?
I don’t like programming in Go, but nothing stops me running go programs on my computer. My computer doesn’t seem to care.
Lua in the kernel!
BSD development mostly works through the classic approach of pretending that if you write C code and then stare at it really really hard it'll be correct.
I'm not actually sure if they've gotten as far as having unit tests.
(OpenBSD adds the additional step of adding a zillion security mitigations that were revealed to them in a dream and don't actually do anything.)
I never used linux because it was built using C++. Never have I cared what language the product was built it. The Rust community however wants you to use a product just because it's implemented in Rust, or atleast as one of the selling points. For that reason I decided to avoid any product that advertises using Rust as a selling point, as much as I can. Was planning to switch from Mac to a Linux machine, not anymore, I'm happily upgrading my mac.
It's an optional tool that can be used to implement drivers now, not forced. If you don't like the idea of another language being supported for implementing a subset of kernel modules, I don't think you wouldn't enjoyed having a Linux machine anyways.
Linux is written in C, my friend.
They had me in the first half of the article, not gonna lie. I thought they resigned because Rust was so complicated and unsuitable, but it's the opposite
It got my hopes up that they had backed off so they could solve their problems before returning to subject the kernel to their language.
Completely tangential but it would be nice if could 'natively' run wasm.
You can do this: https://gist.github.com/jprendes/64d2625912d6b67383c02422727... (one of the solutions, there's a few better approaches)
Linux has been headed in the wrong direction for some time. This just confirms the trend.
I haven't had time to experiment with it yet. How is agent directed development doing with Rust 0-to-1 an 1-inf. product gen?
I’m curious how they’ll manage long term safety without the guarantees Rust brought. That tradeoff won’t age well.
You may want to read the article.
(Spoiler alert: Rust graduated to a full, first-class part of the kernel; it isn't being removed.)
It's late, but I'm having a hell of a time parsing this. Could you explain what you meant?
Rust in the kernel feels like a red herring. For fault tolerance and security, wouldn’t it be a superior solution to migrate Linux to a microkernel architecture? That way, drivers and various other components could be isolated in sandboxes.
I am not a system programmer but, from my understanding, Torvalds has expressed strong opinions about microkernels over a long period of time. The concept looks cleaner on paper but the complexity simply outweighs all the potential benefits. The debate, from what I have followed, expressed similar themes as monolithic vs microservices in the wider software development arena.
Microkernel architecture doesn't magically eliminate bugs, it just replaces a subset of kernel panics with app crashes. Bugs will be there, they will keep impacting users, they will need to be fixed.
Rust would still help to eliminate those bugs.
Go ahead and do it!
Just use MINIX, or GNU Hurd.
Then you can try the existing microkernels (e.g. Minix) or a Rust microkernel (Redox). You already have what you wish for.
You should develop a small experimental kernel with that architecture and publish it on a mailing list.
This is great because it means someday (possibly soon) Linux development will slowly grind to a halt and become unmaintainable, so we can start from scratch and write a new kernel.
You can start from scratch and write a new kernel now! Nothing's stopping you.
Or you can take this as a sign that the linux kernel adapts modern programming languages so that more programmers can contribute :)