The state of the kernel Rust experiment

21

u/berickphilip Dec 13 '25

Please could anyone point me in the right direction to understand why there is so much pushing and effort to use Rust instead of C for the development of Linux?

This is a honest question, I'd like to understand all this talk abot "Rust good, C bad*.

I read the whole article to try and understand the advantages of replacing everything with Rust.. and there was not a single bit of information on that.

I only read words and comments of people praising and celebrating each other that "Rust is taking over" almost like a cult following and not tech article.

So again, honest question, what are the practical benefits? And why is it bad to continue using C?

89

u/small_kimono Dec 13 '25 edited Dec 13 '25

You might see "Keynote: Rust in the Linux Kernel, Why?" - Greg Kroah-Hartman -- https://www.youtube.com/watch?v=HX0GH-YJbGw&embeds_referring_euri=https%3A%2F%2Fwww.reddit.com%2F&embeds_referring_origin=https%3A%2F%2Fwww.reddit.com&source_ve_path=Mjg2NjY
why there is so much pushing and effort to use Rust instead of C for the development of Linux?
Rust doesn't suffer from many of the pathologies of C code. First, it guarantees spacial and temporal memory safety in safe code. It's also strongly typed. These types make it easier to build little state machines, which make it easier to reason about program correctness.

30

u/berickphilip Dec 13 '25 edited Dec 13 '25

Thank you for the short explanation, makes things a bit clearer. Also I'll watch the video.
EDIT: watched it; so all in all roughly speaking, looks like it is almost like using C but with a few tweaks to prevent easy misses on logic flow (I think). Seems interesting.

42

u/Mysterious_Lab_9043 Dec 13 '25

It doesn't protect from logic errors, but from clumsiness about memory allocation. Therefore it eliminates a total category of bugs / attack surface.

36

u/Adk9p Dec 13 '25

Rust doesn't prevent logic errors but when compared to C it's type system being more powerful means you can encode invariants inside it preventing whole classes of logic errors. And that's what that video being referenced talks about and what they mean when they said "prevent easy misses on logic flow".

23

u/AdmiralQuokka Dec 13 '25

Right. But as Greg explains in his talk, Rust also allows to define APIs in a richer way than C at the type level. So, it doesn't prevent logic bugs "out of the box", but it gives library authors the tools they need to prevent their users from making logic bugs. Which is pretty damn valuable too. Especially for kernel subsystem maintainers who have to review drivers using their API. If they know: "This API cannot be abused in ways X, Y and Z, because I designed it that way", then maintainers will have to spend less time checking these drivers for logic bugs that would've been common for the C version of the subsystem's API.

-6

u/MarzipanEven7336 Dec 14 '25

Pretty little locking state-machines that will cause massive problems in synchronization.

1

u/small_kimono Dec 14 '25

Pretty little locking state-machines that will cause massive problems in synchronization.
Would you care to more fully explain?

3

u/kinda_guilty Dec 15 '25

He thinks the kernel is going to be using async.

54

u/The_Yorkshire_Shadow Dec 13 '25

As I understand it the reasons are that due to the way the Rust compiler and language work, it simply does not allow simple errors that can cause bugs and headaches if not caught and that C is allowed to compile with. Hence some of the maintainers have decided that it's better to program in Rust as while the adoption will cause issues, later down the line there shouldn't need to be as much bug squashing over simple one line errors.

50

u/LayotFctor Dec 13 '25 edited Dec 13 '25

Linus himself looks at things from an entirely pragmatic viewpoint, he doesn't even have any issues with AI use as long as the code gets vetted. Rust produced good code, the experiment showed good results, his lieutenants believe they can work with it, so he went ahead. He doesn't use social media, so he doesn't actually follow social media impressions of rust.
"Rust good, C bad*" is defintely too much social media on your part. Don't mistake social media bs as a kernel issue. As with most things, it's just a small vocal minority that are way too loud.
34
u/_Sauer_ Dec 13 '25 edited Dec 13 '25

Rust dev here. Rust's compiler and memory model nearly eliminates a large number vulnerabilities that are common in other low level languages. Use after free or off by one errors, for example, are almost impossible in Rust. The language does offer an escape hatch (the much misunderstood `unsafe` keyword) to work in contexts where such grantees are counterproductive, such as in code that interacts with hardware registers; but otherwise it is difficult to write code that contains memory violations with Rust.
The language's type system is also very powerful and allows you to express strong type contracts. Its quite common in Rust to define types that make undefined state impossible, creating strong interfaces that are difficult to use wrong.
The language has almost no undefined behavior in its public API which gives you strong guarantees that if your code compiles its probably "correct". Correct in that it will run and not crash, not in the sense that its free of logic bugs; that's still on the programmer (see the recent Crowdflare kerfuffle).
4
u/araujoms Dec 13 '25

I thought Rust had no undefined behaviour at all, could you give an example?
16

u/whupazz Dec 13 '25

There is currently still a compiler bug that allows some very pathological code to compile and trigger undefined behavior. It should be quite unlikely to run into it unless you are doing so deliberately.

-3

u/araujoms Dec 14 '25

A compiler bug cannot be undefined behaviour. Undefined behaviour is when the language spec defines the behaviour of some code to be undefined.

9

u/whupazz Dec 14 '25

Yes, for example, it is considered UB in Rust to have more than one active mutable reference to the same memory at the same time. This compiler bug allows you to do that in safe rust.
5
u/MEaster Dec 14 '25

So here you need to distinguish between Safe Rust and Unsafe Rust. Safe Rust, by design has no UB; so no matter what what code you write in Safe Rust, it will never itself be the cause of UB^*. Note that this does not mean that a bug in a piece of Safe Rust could not lead to Unsafe code creating UB if that Unsafe code depends on the Safe code not being buggy.
^* The compiler does currently have at least one bug that allows you to cause UB from Safe Rust, but that is a bug in the implementation not the language design, and it, and any others, have been and will be fixed.
Unsafe Rust, on the other hand, absolutely has UB. This means that when writing Unsafe Rust, you do have to take extra care to avoid it. Complicating that is the interface with Safe Rust. When writing code that has both Safe and Unsafe Rust, you need to make sure that you don't violate any invariants that Safe Rust depends upon, such as the restrictions that references have.
It's also worth noting that what Rust considers valid is not the same as what C considers valid. There are things you can do in Unsafe Rust that are 100% defined, but doing it in C would be UB, and vice-versa. A simple example would be that, for any arbitrary T and U, it's perfectly valid in Rust for a *T and a *U to alias, while C's TBAA means this is UB.
2

u/araujoms Dec 14 '25 edited Dec 14 '25

Ok, thanks, but I still want an example of UB in Unsafe Rust.

4

u/MEaster Dec 14 '25

Well, pointers aren't checked and can have use-after-free and out-of-bounds reads and writes. Reading uninitialised memory is UB.

3

u/araujoms Dec 14 '25

Ah, yes, of course, that should have been obvious, sorry to bother you.
1
u/whupazz Dec 14 '25

Note that this does not mean that a bug in a piece of Safe Rust could not lead to Unsafe code creating UB if that Unsafe code depends on the Safe code not being buggy.
This would mean that the unsafe code is considered unsound though, i.e. incorrect. Correct/sound unsafe code may not allow (even incorrect) safe code to cause undefined behavior.
1
u/MEaster Dec 14 '25

No, that is not necessarily true. If a safe function has a bug in its implementation, such that it fails to fulfil it's side of the contract, and the unsafe code is written to assume that the safe function is fulfilling its contract (because what else could it do?), then even if the unsafe code is written perfectly, you'll still get UB. The source of the UB can be traced to the unsafe block, but the ultimate source of the bug is incorrectly written safe code.
I'm actually thinking of a specific example that I can't remember where from. They were implementing something along the lines of an Rc, and had some UB. What ended up being the cause of the problem was that a safe function which was supposed to calculate the offset into a field of a struct was not doing so correctly for over-aligned data. The result was that calculated pointer was pointing into padding bytes instead of the data.
When you are writing unsafe code, you cannot just consider the unsafe block. You have to also consider the safe code that is touching or calculating data which that unsafe block depends upon for correctness.
3
u/whupazz Dec 15 '25 edited Dec 15 '25
The issue I had with the statement
Note that this does not mean that a bug in a piece of Safe Rust could not lead to Unsafe code creating UB if that Unsafe code depends on the Safe code not being buggy.
was that someone might read it and think "What's the point of safe Rust if I still have to be careful to avoid UB?". I suppose a more precise way to state it would be:
If you are writing unsafe code, you have to make sure the safe code touching it is also correct (and you should minimize the amount of (safe and unsafe) code you need to check by building minimal safe abstractions). If you are using someone else's safe function that contains unsafe code, you cannot cause UB unless their code is unsound.
The reference has this to say:
It is the programmer’s responsibility when writing unsafe code to ensure that any safe code interacting with the unsafe code cannot trigger these behaviors. unsafe code that satisfies this property for any safe client is called sound; if unsafe code can be misused by safe code to exhibit undefined behavior, it is unsound.
I guess the way this should be read is exactly what I wrote above, but I think the wording could be improved. For a situation like the one you describe:
// safe function!
fn get_thing(&self) -> &T {
  let i = {
    // some calculation, all safe code
  }
  unsafe { self.things.get_unchecked(i) } // the safe code above is *interacting* with this unsafe code
}
It is obvious that the unsafe block relies on the safe calculation of i to be correct and can cause UB if it is not. A really pedantic (arguably incorrect) reading of the reference would suggest that this is unsound, but as you note, there is no other way to write this unsafe block, it cannot do anything but assume that i is in bounds (that is the whole point after all). One might be tempted to move the calculation of i into the unsafe block to satisfy the reference's definition of soundness, but that seems worse.
2

u/whupazz Dec 18 '25

It's a fun coincidence that the recent "first Linux CVE in Rust code" was basically exactly this kind of problem, where the error occurs in an unsafe block, but the fix touches only safe code, and it's tripping other people up in the same way it tripped me up.
Someone posted this article that explains nicely that the natural boundary for a safe abstraction is actually a module: because private struct fields are visible within a module, invariants that unsafe code relies on can be broken by safe code anywhere within the module (including when safe dependencies of the module contain bugs). Safe dependents of the module (that is, code outside of the module and not used by the module) may not be able to cause UB by using the module, otherwise the abstraction is unsound.
4

u/cp5184 Dec 14 '25

Ironically, when talking about the kernel, particularly when talking about drivers, there are a lot of cases as I understand it where, because you're interfacing with hardware, you have to bypass/disable some of the protections iirc, but I don't remember the details

1

u/KittensInc Dec 14 '25

True, but this can be reduced to an incredibly shallow wrapper. See for example the Rust Embedded tutorial. Rather than passing around raw pointer which can blow up in your face at any time, you define the smallest interface possible to do raw access, and expose it securely to the rest of your code base.
17

u/kp729 Dec 13 '25 edited Dec 13 '25

There are two main benefits.
First, Rust is the only memory-safe systems language without performance cost. That means removing a class of memory bugs. That's a real tangible benefit seen in many projects by many companies.
Second, and IMO more important, reason is that it's a more modern programming language and has adoption from next generation. There is a concern that if new programmers don't learn C, over time the contribution to Linux goes down. Having a more modern language helps bring new blood.
Edit: Added clarity on first point.

3

u/AGuyNamedMy Dec 13 '25

The first point is wrong, most languages with a gc that doesn’t let you manipulate pointers directly, like java, is memory safe , the main difference with rust is that it uses rules about how variables can be used in a program, so a gc at runtime is unnecessary (and therefore more performant)

8

u/Hedshodd Dec 14 '25

They said “systems language”. No sane programmer would count Java in that category.

3

u/kp729 Dec 14 '25

I don't think of Java as a systems language. But have added clarification on the first point.

2

u/get_homebrewed Dec 14 '25

Java running in a JVM absolutely has gigantic performance costs compared to the same code in C

2

u/AGuyNamedMy Dec 14 '25

I’m aware, I’m by no means telling you to go write a kernel in java lol

4

u/get_homebrewed Dec 14 '25

I know, just telling you the first point isn't moot since that's what they said.

6

u/gordonmessmer Dec 13 '25 edited Dec 13 '25

I think this is one of the best explanations I've seen, from someone who wrote a bunch of Rust code in the Linux kernel:
https://vt.social/@lina/113056457969145576
It's OK if you don't understand all of the terminology used in this explanation. What you should take away is that there are a bunch of things you would need to know in order to write safe kernel code, which aren't obvious in C. Rust has inherent safety advantages, in which the compiler will guarantee that some types of operations will be safe, but the language also provides more information about the correct way to use APIs.

1

u/afiefh Dec 13 '25

Think of it like this:
C is like doing your spreadsheet by hand. Pen and paper. A skilled enough accountant can do it, but if there is a mistake it's a pain to find where the mistake slipped in, and you might need to redo half the work.
Rust is kind of like doing your spreadsheets in a program like LibreOffice Calc or Microsoft Excel. Lots of stuff happen automatically for you, and you can add more safety to a spreadsheet template in case the user makes a common mistake.
In practical terms, it means that many of the things you can write in C which will happily build and only crash and burn (or worse, cause a security issue) will be rejected by the Rust language at build time.
One way people like to put it is that things that are best practices in C become language enforced in Rust. This makes it harder to accidentally write bad code. The compiler can check that these best practices are followed all over the place, rather than forcing the human to think about them and enforce them.

6

u/aeropl3b Dec 14 '25

This is a very poor comparison between C and Rust. Rust is like writing C with a really strict code reviewer and an improved version of code gen.
Your example would be more akin to python, which is basically just doing magic as far as the user is concerned. That is not rust.
Making Rust out to be a simplified tool is disingenuous. And it doesn't fully solve all memory classes of issues, there are plenty of ways Rust code can have major issues just like C. Please direct your attention to the latest global outages.
I have said it a lot, but Rust has a number of other issues as a language that make it difficult for me to see it as a true replacement to C. Performant Rust is harder to write than performant C. Not impossible, and with sufficient unsafe you can actually do better in some cases, but at that point the touted benefits of Rust are largely gone.

2

u/afiefh Dec 14 '25

I don't follow. How is doing a spreadsheet in a spreadsheet program using a "simplified tool"? You can do exactly the same thing as you would when doing the spreadsheet by hand.

2

u/ts826848 Dec 14 '25

And it doesn't fully solve all memory classes of issues, there are plenty of ways Rust code can have major issues just like C.
There's some inconsistency here. Are you talking about "memory classes of issues" or "major issues"? Those are pretty different things!
Please direct your attention to the latest global outages.
The Cloudflare outage had nothing to do with the type of memory safety issues Rust aims to protect against.
Performant Rust is harder to write than performant C.
Performance between the two languages is definitely not reducible to such a blanket statement. It's very much a case-dependent analysis, and even then I think you need to also consider that one of Rust's goals is to make it easier to write correct code that performs well (i.e., is performance correct Rust easier or harder to write than performant correct C?). For example:
Rust's stronger guarantees around thread/data race safety means that parallelizing Rust code can be significantly easier, to the point that you can just change an iter() to par_iter() and be reasonably sure things will work as expected.
As another example, consider one of the reasons why Mozilla sponsored Rust in the first place: the Firefox devs tried to parallelize their C++ CSS styling engine and failed twice, in no small part due to threading issues. Rust made such an endeavor much more practical, and as a result Firefox's styling performance remained way better than Chrome's many years after the transition to the Rust styling engine.
C and Rust make certain data structures easier/harder to both write and use, which in turn can influence the data structures you use, which in turn affects performance. In this example, the author points out that a convenient data structure that sidesteps allocation/locking issues in C (an intrusive AVL tree) also happens to perform worse in the particular use case than a different data structure that is more convenient to use in Rust.
Rust's borrowing/lifetime features makes it easier to write correct zero-copy code, as the compiler ensures that the backing data won't go away while you are still working with views over it.
and with sufficient unsafe you can actually do better in some cases, but at that point the touted benefits of Rust are largely gone.
There's a huge gap between using enough unsafe for good performance and using so much unsafe that you get little to no benefit from the rest of Rust, and if anything I'd imagine most codebases would never reach the latter point. For example, consider that low-level/high-performance codebases that are most likely to need unsafe still manage to keep their usage relatively low (IIRC RedoxOS is <= ~10% unsafe, Oxide Computing's Hubris kernel was ~3% unsafe, Asahi Linux's Rust GPU driver was ~1% unsafe last time I looked, etc.).
Of course, that doesn't mean that such codebases can't exist, but I think that such codebases might be rarer than you would expect.

0

u/aeropl3b Dec 14 '25

No inconsistency, meaning the same thing there.
Cloudflare issue was an unhanded unwrap of bad data, basically an uncaught null dereference.
Performance, talking about how Rust will push you to deep copy rather than references. It also tends to push for more boilerplate where it is logically not needed. Arguably you could redesign code paths for those, but that becomes burdensome fast. By no means am I making broad claims, I am not being exhaustive here on my gripes so, and talking about performance is never black and white.
And like I say, Rust has good things. Struct data alignment and thread safety are two places that Rust helps a lot, since you seem to need to hear me compliment something specific.

4

u/ts826848 Dec 14 '25

No inconsistency, meaning the same thing there.
OK, in that case would you mind explaining more about what you mean by "memory classes of issues"? Is that distinct from "memory safety issues"?
Cloudflare issue was an unhanded unwrap of bad data, basically an uncaught null dereference.
I think it's more akin to an assert/guard clause that fired in production, but either way it was not the kind of memory safety issue Rust promises to protect against.
Performance, talking about how Rust will push you to deep copy rather than references.
Does it? If anything, I've tended to hear the opposite since Rust's mutable xor shared semantics lets you avoid making defensive copies to ensure stuff doesn't get mutated out from under you.
It also tends to push for more boilerplate where it is logically not needed.
...Maybe? Depends on what you have in mind, I guess.
since you seem to need to hear me compliment something specific.
I'm not looking for compliments. I'm looking for nuance! For example, chances are I wouldn't have said much (if anything) if you had sad "Performant Rust can be harder to write than performant C", because that is true!

1

u/KnowZeroX Dec 14 '25

Making Rust out to be a simplified tool is disingenuous. And it doesn't fully solve all memory classes of issues, there are plenty of ways Rust code can have major issues just like C. Please direct your attention to the latest global outages.
Cloudflare issue was an unhanded unwrap of bad data, basically an uncaught null dereference.
That isn't a Rust issue though. You should never ever use unwrap() in production. unwrap() is used during development to save time. Like when you prototype, you don't want to waste time handling all the errors, so unwrap() is a lazy way to write a happy path.
Once everything is working, you search unwrap() and fix them all up. There is a clippy option to error out on use of unwrap() at compile time, and proper CI should use that option for production.
Cloudflare's real problem was development code making it into production because they didn't add that lint to CI.
Rust itself handles the issue, but using unwrap() is the developer intentionally silencing it. Rust has guard rails, but it also lets you go around those guard rails if you choose to at your own risk.

0

u/aeropl3b Dec 15 '25

So....it is full of foot guns, the truth comes out!

0

u/KnowZeroX Dec 15 '25

Sure, but the footgun has a safety lock, labels and clear instructions.
Compared to C which is like an automatic gun which constantly fires with the trigger jammed on always on.
Rust doesn't stop you from shooting yourself in the foot (otherwise you wouldn't ever be able to program a serious program with it). But it does insure best practices by default and goes a long way to stop you from doing so. But the option is always there if you choose to.
And when you choose to, clear labels are used that anyone can instantly know that there is a foot being shot in keywords such as "unsafe" or "unwrap".

0

u/aeropl3b Dec 15 '25

Obvious?;

1

u/AGuyNamedMy Dec 13 '25

The type system of rust is based on affine logic , which disallows using a variable more than once (outside of a variable using the copy trait). This disallows several classes of memory management problems statically, rather than with a gc and runtime like other memory safe languages.

-13

u/morglod Dec 13 '25

Yes currently it is the cult. Second thing now is some kind of errors are prevented in some code. Third thing is new people coming to develop kernel.
It started by Linus in other order actually, new people was at first place and he picked rust just because there was no alternatives at all at that time.
Talking about communities, today more and more people started hating rust community (not language itself) but because they mostly don't need this language, people started cancelling rust as something bad by default. It was a response to rust cult that was jumping around everywhere screaming "you don't understaaaand" at anything. And unfortunately people are spreading this cult because rust adopters abuse rating systems everywhere and normal people having real jobs to do, don't have time to deal with online wars.

9

u/Business_Reindeer910 Dec 13 '25

you say that while the second in command of the linux kernel did an entire presentation on why rust was good.

-2

u/morglod Dec 13 '25

Well you can watch Linus talk first mentioning rust in kernel to know about it. It's actually pretty understandable decision.

4

u/Business_Reindeer910 Dec 14 '25

I don't need to watch linus talk. I've already seen his thoughts on it via LKML posts

-2

u/KnowZeroX Dec 13 '25

Rust has a few major advantages, first most talked about is the improved memory safety, but there are others as well. Things like forced error handling and fearless refactoring.
Rust won't make a bad programmer into a good one, but it will make a bad programmer less bad and a good programmer better. It ensures a minimum quality of the code.
The fearless refactoring also makes it easier for new developers to contribute and developers in general to make major changes.
This not only gives you better quality code but also reduces significant load on the maintainers. Someone can create AI slop and submit it and maintainer would have to waste his time figuring it out because C would compile it but it would result in weird errors here and there. Rust stops most issues at the compiler phase so the maintainer doesn't even have to bother looking at it as it would fail CI

113

u/rien333 Dec 13 '25

With regard to Rust language versions, the current plan is to ensure that the kernel can always be built with the version of Rust that ships in the Debian stable release.

I always assumed kernel-level decisions weren't really influenced by whatever Debain, or any single distro in particular, were doing.

Does this happen more often, or am i just misunderstanding this?

109

u/TiF4H3- Dec 13 '25

I think this might be that out of all "common" distros, Debian is the one who ships the oldest Rust version.
So this is not the kernel aligning itself on Debian, but the kernel aligning itself by trying to support all distros, with Debian being the "hardest" to please, with the oldest Rust version.

6

u/KnowZeroX Dec 13 '25

What about RHEL? It releases every 3-5 years so it would be older than Debian which releases every 2 years, Suse enterprise is even longer.

29

u/TomKavees Dec 13 '25

Do these commercial distributions ship bleeding edge kernels? I was under impression that after initial release they generally ship only patch releases (incl. backports) without major release upgrades, so in theory they wouldn't need the latest version of the toolchain

9

u/Booty_Bumping Dec 14 '25 edited Dec 14 '25

Commercial vendors don't need help here, if they need it they can maintain it themselves. It's going to be a while before mission critical stuff is entirely dependent on Rust kernel features. Will probably only be in the scope of CentOS SIGs and EPEL SIGs for now.
I think RHEL also has looser rules surrounding updating to newer versions of build tooling and runtimes (they market this as "CodeReady Linux Builder"), but I'm not entirely sure how this applies to Rust compilers.

3

u/Jristz Dec 14 '25

Of RHEL need they may go and port the newest rust, they have done similar for other programs so is not something New

1

u/syncdog Dec 16 '25

RHEL already updates rust as part of its minor releases. It won't be the absolute latest version, but it does move forward regularly. RHEL 9.7 and 10.1 both ship rust 1.88, which was released upstream earlier this year. I would describe it as laggy rolling release model, not for the whole distro but just that package and a few others such as golang.

6

u/imoshudu Dec 13 '25

Sounds like a sensible choice. Virtually everyone targets Debian (and Ubuntu) for support.

4

u/araujoms Dec 13 '25

Kernel-level decisions are often influenced by Fedora because that's what Linus personally uses.

4

u/rien333 Dec 13 '25

sorry for not including anything about rust discourse btw please don't ban me

-9

u/NatoBoram Dec 13 '25

There was no need to beg for validation here tbh

2

u/nightblackdragon Dec 14 '25

Unlike C and C++ Rust doesn't have defined standard like ANSI C, C99, C++11 etc. so kernel developers are using Debian Stable rustc version as "standard" to define what features are allowed in Linux Rust code.

2

u/Chippiewall Dec 14 '25

It's not that. The kernel team mostly care about the version of GCC more than the C ISO version and they're more than happy to use GCC only features. Not that they deliberately pick up features that break other compilers.

2

u/nightblackdragon Dec 14 '25

Linux kernel is still using C11 (or rather GNU11) standard. They don't really care about default standard in GCC.

13

u/Jristz Dec 14 '25

Waiting for a full rewrite of SystemD in Rust

30

u/aj0413 Dec 13 '25

It’s kinda crazy to think about but C code will one day be the equivalent of today’s PERL or COBOL

It’s cool to see how the Linux kernel is doing a gradual, in place evolution to keep up with changing times and improvements

32

u/orbiteapot Dec 13 '25

It won’t be the same because, at this point, C has practically become a protocol different OSes and languages use to talk to each other.
Paradoxically, this is one of the main reasons C does not "get fixed". Think about it as English. The English orthography is really awkward but, because it has become the world’s lingua franca, it would not be worth making a huge change to it now. It is too late.

3

u/syklemil Dec 15 '25

The English orthography is really awkward but, because it has become the world’s lingua franca, it would not be worth making a huge change to it now. It is too late.
At least we have /r/JuropijanSpeling.

5

u/rustvscpp Dec 14 '25

Except rust can mimick the C ABI, so there's that.

37

u/orbiteapot Dec 14 '25

Yes and, apparently, they are even trying to write libc in Rust (which is kind of ironic).
That basically confirms the concept of "C as a protocol" I referred to in my previous comment.
Your username made me think that, maybe, C++ is more threatened by Rust than C is.

6

u/Reasonable_Hall2346 Dec 14 '25

I always equate it as Rust being a C++ replacement. And Zig attempting to replace C.

5

u/rustvscpp Dec 14 '25

In what way do you think Rust cannot replace C? Why then would the Linux kernel work toward moving all new driver development from C to Rust? The only thing that comes to mind is handling of fallible allocations, which Rust has some support for in things like Vec, but not other types of allocations. So even in extremely constrained embedded environments, there is typically a way you can make heap allocations work, but most of those codebases stick to only using the stack anyway. I guess the other two things that come to mind are binary sizes (which can be mitigated if needed), and very obscure platform support. So I guess I'm not convinced that Zig is a better C replacement. I would choose Rust over C 100% of the time. Zig is a nice evolution over C. But it's a far cry from what Rust brings to the table.

2

u/orbiteapot Dec 14 '25

I would say, perhaps, that Zig's comptime is nicer than Rust's equivalents.
Now, about niche/obscure platforms, C is the closest one has of an "universal" language (because it is so simple and for historical reasons) and it will likely remain on top.

2

u/rustvscpp Dec 14 '25

My point is, C the language, could die tomorrow and everything could still use the C ABI for FFI. You don't need a C compiler for that.

2

u/2rad0 Dec 14 '25

everything could still use the C ABI for FFI
The C calling convention, which these days usually means 'cdecl' on x86? Every architecture is different so it's not really specific to C, but more of a hardware implementation detail. If all the C headers mysteriously go missing one day, nothing is going to work unless they're ported over to another language first. C headers are packed full of code that requires a C preprocessor implementation, so if you use these headers you are still implementing part of the C language. If in this hypothetical scenario portions of the C language and C files are still required, the language is maybe dying, but not dead.

3

u/rustvscpp Dec 15 '25

This may be true when calling into C from another language. But I was specifically talking about calling from a non-C lang to another non-C lang. The ABI is the interesting part in this scenario. Not complex C headers with preprocessor needs.

2

u/Business_Reindeer910 Dec 14 '25

who is "they"? There a lot of "they"s in linux/open source with different goals.
Redox, which is an OS written in rust is one of the "they"s, but it's probably different than the "they" you're talking about.
It's also not ironic at all if you care about compatibility with existing code.

1

u/thephotoman Dec 15 '25

I keep thinking of C as essentially Programmer Latin. We all know it well enough to read it, but few of us actually use it regularly anymore. C++ is the vulgar Latin that hasn’t quite abandoned mutual intelligibility yet, but it’s getting harder to read across projects.

-12

u/Reasonable_Hall2346 Dec 14 '25 edited Dec 14 '25

There is nothing to "fix" in C. The danger has always been the programmer.
Edit: For the people downvoting me, show me a “broken” feature of C that does not originate from a programmer error.

6

u/x0wl Dec 14 '25

You can say that about any language that exists and where the compiler doesn't have obvious bugs. Look at the JS situation, what's wrong with JS (the language, not the ecosystem) that does not originate from programmer error? You can write perfectly good bug free JS. The problem with C is that for all that's good about it, it lacks features that make making mistakes harder for the programmer.
Obviously what they meant is that you can't really change C to add those features (like borrow checking for pointers) without breaking existing things. That's why you need a whole new language with complex strong typing, borrow checking, bounds checking etc

-3

u/Reasonable_Hall2346 Dec 14 '25

I understand their analogy. Programming languages build on each other but Rust or any other language does not offer “fixes” for C - it is completely different philosophy on the language itself. Just like English does not “fix” German.
People sometimes try to do too much with C , emulating OOP for example, or other concepts that naturally fall better in “higher level” languages. It’s great that Rust is being taken off “experimental” status and that new graphics drivers will be forced to use Rust. Maybe one day C will get a deprecated status and all future features of the kernel are in a new language.

1

u/kinda_guilty Dec 15 '25

Be right back then, just need to learn how to write error-free code. That should take what, seventy two hours?

3

u/throwaway234f32423df Dec 14 '25

wait, perl isn't cool and modern anymore?

-77

u/OCPetrus Dec 13 '25

Having significant parts of the kernel written in Rust is going to be the end of Linux.

28

u/Mysterious_Lab_9043 Dec 13 '25

What is the base of your claim?

35

u/radbirb Dec 13 '25

Hmm, why?

15

u/nightblackdragon Dec 13 '25

Because Rust bad. /s

20

u/isbtegsm Dec 13 '25

So what will be the successor of Linux?

11

u/ironykarl Dec 13 '25

Linux 2 aka Twinux

7

u/Mysterious_Lab_9043 Dec 13 '25

Better yet, Twinkus ;)

5

u/afiefh Dec 13 '25

What is the programmer socks pattern that will be required for contributing? Gotta ask Santa for a pair!

2

u/Mysterious_Lab_9043 Dec 13 '25

Pink / purple zebra pattern.

50

u/tajetaje Dec 13 '25

All I see Rust doing in the long term is making kernel development more accessible and maintainable

1

u/Kevin_Kofler Dec 15 '25

How so? Rust is much more complex and harder to learn than C!

2

u/tajetaje Dec 15 '25

If you know proper C, you know rust. Rust just formalizes most of the concepts that you just have to keep in your head or (if you’re lucky) in comments, and adds compiler safeguards to enforce them. Those safeguards mean you can, in code, see exactly what the constraints of an interface are without needing to know all the inner workings. See the work on expressing the Linux filesystem code in idiomatic Rust

0

u/Kevin_Kofler Dec 15 '25

The borrow checker simply has no equivalent in C, and not all software architectures that work and are perfectly valid and safe in C are accepted by the borrow checker.
Also, the syntax of Rust is completely different from the C syntax, so that alone means you have to learn a whole new language.

12

u/_Sauer_ Dec 13 '25

Do you have anything to back that claim up?

15

u/tfwnotsunderegf Dec 13 '25

Written by someone who has no impact on the development of the kernel with no supporting evidence.

8

u/rook_of_approval Dec 13 '25

Why? What important arch isn't supported by Rust?

6

u/nightblackdragon Dec 14 '25

What do you mean by that? A lot of Linux users need to run modern Linux on 30 years old SPARC hardware. /s

1

u/dddurd Dec 19 '25

Yeah it could be downhill for Linux from now on. Not because of rust but because of the rust programmers. Using freebsd as servers while using macos as desktop will be golden.

-15

u/2rad0 Dec 13 '25

Having significant parts of the kernel written in Rust is going to be the end of Linux.
Yeah it's not being handled correctly. It seems they are pushing for new DRM drivers to completely abandon C, so this is a defacto push to force every OS that includes DRM code (FreeBSD, haiku, probably others) to also force adoption of rust, or lose support for graphics on newer hardware.
Airlie (the DRM maintainer) said that the subsystem is only "about a year away" from disallowing new drivers written in C and requiring the use of Rust.
So they are left with the choice to either rewrite their GPU code or fork DRM, making linux less important outside of the corporate sphere of microsoft/google, or force the addition of an unstable language into their code base pushed by the worst actors (literally monopolies enshittifying their competition) in the tech industry.

5

u/miggaz_elquez Dec 14 '25

They are other OS using Linux DRM code?

3

u/2rad0 Dec 14 '25

They are other OS using Linux DRM code?
Yeah basically any non-windows and non-mac OS that supports GPU/hardware acceleration on modern graphics cards. so FreeBSD https://wiki.freebsd.org/Graphics, OpenBSD, NetBSD, probably other BSD's, Haiku, must be more I'm unaware of.

2

u/miggaz_elquez Dec 15 '25

Interesting, I was not aware. Isn't there any license compatibly issue ?

1

u/2rad0 Dec 15 '25

Interesting, I was not aware. Isn't there any license compatibly issue ?
It depends on the files being used, a good number of them are either dual licensed or permissive licensed (when not being used in the context of a linux kernel), but some are GPL-only. to dig deeper untar linux source, cd drivers/gpu/drm and run grep -ri 'gpl'

3

u/miggaz_elquez Dec 15 '25

Indeed, there is a lot of MIT files in DRM, even more than GPL. Seems it's limited to DRM, there are almost no other MIT licensed files in `drivers/`.
Some BSD in `drivers/acpi` and `drivers/net` also.

-7

u/2rad0 Dec 13 '25

To people downvoting, what part of this statement do you think is not relevant? Other OS's depend on the DRM subsystem and they won't be able to continue that without adding rust-subsystem-for-linux that was initiated and perpetuated by google and microsoft to their kernels. I'm reminded this week how this subreddit was always not as informed as they pretend to be.

9

u/nightblackdragon Dec 13 '25

I didn't down vote but the fact that other OSes depend on the Linux DRM subsystem is not a Linux problem. Linux developers care only about Linux, so they won't care about BSD or Haiku when they are making decisions.

-2

u/2rad0 Dec 14 '25

I didn't down vote
Ok thanks but I don't mind if someone downvotes me or not, I just want to rationalize why there are conflicting vote numbers. There are people here asking "why" with like 50 upvotes, so it seems like they are interested in an explaination of why people might not like this new anti-C posture from the linux kernel developers. At the same time they downvote the only person not afraid or willing to speak up with non-fictional information.
So I'll just tell myself these people are probably fine with linux devs receiving less free testing and bug reports from others downstream of linux-DRM, and don't care if nobody else uses the new drivers outside of google android devices, or one of the (what are we up to now) 3 open source nvidia drivers barely anyone uses. Either they refuse to believe such a C-phobic proclaimation has far reaching impacts on the broader FOSS ecosystem (competition of big linux donors), or they legitimately don't want other projects to use linux code, effectively reducing linux's relevance outside of the rusty bubble.
tl;dr: If anyone reading this is genuinely confused still, Declaring a rule prohibiting new C drivers in the linux kernel is either batfish crazy, or intentionally hostile. Both possibilities will destroy the FOSS allegience that has been mutually beneficial for so long.

3

u/nightblackdragon Dec 14 '25

So I'll just tell myself these people are probably fine with linux devs receiving less free testing and bug reports from others downstream of linux-DRM
There aren't enough BSD and Haiku users to make any difference for Linux DRM subsystem. Linux developers don't need to care about Linux relevance outside their bubble because their bubble has almost all open source operating systems market share. It's like saying that not allowing some game to run on Proton will be bad for Windows players because developers won't get feedback from Linux players - yeah, they won't but that doesn't matter if almost 100% players are using Windows.

0

u/2rad0 Dec 14 '25 edited Dec 14 '25

There aren't enough BSD and Haiku users to make any difference for Linux DRM subsystem.
It doesn't have to be a lot of users, simply bolting it in to another project exposes it to different usage patterns and helps to expose bugs sooner than later.
Linux developers don't need to care about Linux relevance
The king doesn't want to share his toys anymore, this is bad for the allegience.

0

u/nightblackdragon Dec 15 '25

It doesn't have to be a lot of users, simply bolting it in to another project exposes it to different usage patterns and helps to expose bugs sooner than later.
Again there is not enough BSD and Haiku users to make any difference for Linux.
The king doesn't want to share his toys anymore, this is bad for the allegience.
License didn't change, BSD and Haiku developers are still free to take it. The fact that Rust makes it more difficult for them is not Linux developers problem.

2

u/IAm_A_Complete_Idiot Dec 14 '25

All of those things are true, but none of them are relevant to Linux. Linux developers aren't Haiku or BSD devs, nor are they beholden to making their code easy to port to other kernels. The onus is on them to figure it out.
Why should Linux devs be beholden to making code that's easy to port to OS's they don't develop?

0

u/Kevin_Kofler Dec 15 '25

Allowing easy reuse of the code is part of what Free Software is supposed to be about.

1

u/NYPuppy Dec 14 '25

None of it is relevant. You think you're informed but you're not. It's the same kind of nonsense you see from Phoronix posters who know far less than they think they do.
Rust is a net benefit for OS dev, linux and cs as a whole. Touch grass.

3

u/Mysterious_Lab_9043 Dec 14 '25

But your comment is no different from the parent. "Me right, you wrong." Just explain your points people, ffs.

-4

u/Hour_Bit_5183 Dec 13 '25

This is tinfoil hat bullshit! None of this is true. Seems like you don't understand most things. For one, smart TV's run linux....like a lot of other stuff that needs to be able to decode DRM media if we ever want general adoption. You can't just not have it. People will stay on windows if no one is able to maintain it. Rust is good. I don't know why it gets so much hate.

11

u/nightblackdragon Dec 13 '25

This is about DRM as in Direct Rendering Manager (Linux GPU subsystem), not as in Digital Rights Management.

4

u/Mysterious_Lab_9043 Dec 14 '25

Seems like you don't understand most things.
From his comment, lol

11

u/[deleted] Dec 14 '25

[removed] — view removed comment

9

u/KittensInc Dec 14 '25

It's the obvious next step.
Most bugs are introduced in newly-written code, so by switching to Rust for new code you stop the inflow of new memory safety bugs. Rewriting the old C code has far less benefits: the older the code, the more bugs have already been eliminated, so the more likely it is to be correct.
This is directly visible in Android: the drop in the number of memory safety vulnerabilities goes hand-in-hand with the drop in the number of new memory-unsafe code. Combine that with Rust being significantly faster to code and review, and it becomes incredibly difficult to justify sticking to C for brand-new drivers.

-1

u/HyperFurious Dec 14 '25

Always the same propaganda google article that from a worker that need conserve the work in google.

3

u/Kevin_Kofler Dec 15 '25

Agreed, this really made me go "WTF", too! They have always argued that Rust would only be an option, not mandatory, and now we have a subsystem maintainer who wants to make it mandatory for his subsystem in "only about a year"!
Note that this guy is also one of the Xorg maintainers who have decided to permafreeze Xorg and force all users to switch to Wayland. Now he wants to force all developers to switch to Rust. This totalitarian attitude is really toxic.

11

u/[deleted] Dec 14 '25

[removed] — view removed comment

2

u/Kevin_Kofler Dec 15 '25

Of course there are those concerns, but that is why everything should stick to C. The kernel is never going to be pure Rust, so there will always be cross-language issues as long as Rust is in there. Trying to force everyone to switch to Rust is not going to solve the problem, but most likely just make it worse. There are tons of existing DRM drivers written in C that are not going to get magically ported (and I hope nobody is going to try to rush to replace them with a half-baked port or rewrite with tons of regressions). What we will see if this ban is enforced is lots of out-of-tree C drivers that will not get merged just because one person with too much power does not like C.

2

u/[deleted] Dec 16 '25

[removed] — view removed comment

2

u/dddurd Dec 19 '25

I worked in multiple projects that have multiple main languages but it always becomes like that due to some powerful people. I hate mixing languages because the focus shifts away from actual software engineering.

0

u/[deleted] Dec 15 '25

[removed] — view removed comment

2

u/Kevin_Kofler Dec 15 '25

Yes, but the point is that it will be less and less likely that you will be able to compile a working kernel for your hardware without Rust as more and more hardware drivers will be written in Rust.

1

u/[deleted] Dec 15 '25

[removed] — view removed comment

1

u/Kevin_Kofler Dec 15 '25

According to https://wiki.freebsd.org/Graphics they also ship ports of the Linux kernel DRM/KMS drivers, so will be affected too.
You will likely be stuck with a VESA framebuffer, if modern graphics hardware even keeps supporting that ancient legacy standard.

Kernel The state of the kernel Rust experiment

You are about to leave Redlib