>The next article in this series will look at the design of the interface between the C and Rust code in the kernel, as well as the process of adding new bindings when necessary.
This is the actual useful one since so little of the kernel has Rust bindings. When I tried to implement a filesystem driver in rust I spent most of my time trying to write bindings instead of trying to write a filesystem.
I'm curious, who's driving the interest in Rust. Do people learn it in CS degree's and thats all they know? Do orgs like it as a language because its considered safer in the sense that there are usually less bugs compared to C++ (and hence get it introduced into CS degrees)? Is it that C++ has become an abomination over time with added features? Cant we just use C++ as C with polymorphism and encapsulation? Is it generics that are the sticking point (and people don't like STL)? Or is it simply that a new gen just want to have their own thing to differentiate themselves from the oldies... its more cool.
I personally invested a lot of time and effort into learning C/C++ and the only new language with enough difference to come along that was worth learning was Python imho. Not sure what significant differences Rust brings that warrant throwing all that knowledge away and starting again.
My interest in Rust comes from getting frustrated with C's type system. Rust has such a nice type system and I really enjoy the ownership semantics around concurrency. I think that C++ written "correctly" looks a lot like Rust and libkj [1] encourages this, but it is not enforced by the language.
Rust (without use of `unsafe`) eliminates several entire classes of bugs (including bugs that comprise the majority of security related memory safety issues) while providing performance comparable to C/C++.
That is really all there is to it - it is just the better option for systems programming by almost all available metrics, and I say this as someone who has been coding C and C++ professionally for coming up on 25 years.
Safe Rust is actually safer than Java because Java still has data races (that happen when you don't use correct synchronization when doing multithreaded code). In Java data races aren't as catastrophic as C (that is, it's not UB), but they are still a very severe kind of bug.
In Safe Rust, data races can't happen because you can only share stuff between threads if they are either synchronized or read only - attempting to share data that can't be accessed by many threads results in a compile time error.
Also: Java depends heavily on the GC to have memory safety. There are probably some kernels that manage memory with GCs, but for most of them it's not appropriate.
- Java's use of GC and a large runtime makes it inappropriate for many use cases
- Java had a pretty slow startup time, which makes it a poor fit for many CLI applications and similar
- Java has historically had pretty poor support for interoperating with c libraries (although this is improving with project panama)
- Rust has a richer, more powerful type system than Java (although scala's is more comparable)
- Rust's affine types (lifetimes) actually prevent certain types of bugs that occur in languages like Java as well. Things like using a connection or file handle after it is closed, forgetting to release a lock, not properly synchronizing access to memory between multiple threads, etc.
One reason I can think of is its memory management model gives programmers more control than a garbage collector. With the borrow checker, you know when your variables will get dropped/deallocated, but a garbage collector is not necessarily as controllable.
Rust is interesting because it's the first language to really try to compete in the same space as C and C++ in quite a long time. Part of being a newer language is that it doesn't have to work around the baggage of horribly bad past decisions (e.g., null-terminated strings, or implicit integer promotion). Part of it is also that it can adopt newer language features (e.g., structured binding or pattern matching) and have it mesh well with the language rather than having some weird workarounds.
For many people, the most interesting aspect of Rust is that it builds into its type system a set of rules that makes it much more practical to avoid memory safety issues or concurrency issues--lifetimes and Send/Sync are an absolute godsend for such programming, especially because it means you get the compiler to kick you in the face when you screw it up. Rather famously, Mozilla attempted a couple of parallel layout engines in C++ but their attempts all failed, because it just wasn't feasible to shake out all of the concurrency issues; their first attempt at doing so in Rust had none of those issues. It's not that the rules are complicated or hard to follow, it's that in large codebases, the invariants you need to uphold are described only in comments and can be easy to forget.
As a person that occasionally daytrips into Rust and Zig, I'd imagine some number of us are coming from higher level languages (JS/TS, Python, etc) as our daily drivers and interested in what performance we could get closer to the metal.
In those cases we don't have a particular investment in C/C++, we don't know the differences between gcc or clang, we are used to package managers, don't manage header files, and things like comfy error messages and "if it compiles it's reasonably safe tm" are better than... Not having those things.
Meanwhile, outside of things like CUDA interop I don't know what the compelling case for C/C++ even is for someone who isn't invested.
Most of the interest I have seen is in pursuit of security.
A few sources have cited that something like 70% of vulnerabilities are rooted in memory safety issues.
A language that makes it impossible to introduce 70% of the security bugs is appealing.
I think it aims to have the features of C++ that are required for modern safe systems programming, but not all the baggage that comes with such a large and historied language.
Rust has more and nicer language features compared to c++ that you can use to make the code readable.
I wish rust had overloading and specialization though.
> I personally invested a lot of time and effort into learning C/C++ and the only new language with enough difference to come along that was worth learning was Python imho. Not sure what significant differences Rust brings that warrant throwing all that knowledge away and starting again.
Ive written a little c++ professionally along with rust. I really don't think rust is that hard to learn. Especially compared to c++, I'd be embarrassed to tell people i "know" c++ despite using it a bit. there's so much to writing c++.
I think you would be a competent rust programmer in a couple weeks, have a pretty good grasp on the language and be able to pretty much contribute to any in progress project.
You could spend a weekend going through the rust book and have a good idea of the language. I dont think I could say that to anyone about any c++ book lol
I mean I don't mind learning it if it solves problems and is reasonably enjoyable to program in (which I find C/C++ to be) but the rebel in me doesn't want to conform to what big business/politics wants I guess. I know thats a terrible metric to use in this field.
I think it's the rust folk who are the rebels. Status quo types would never advocate for something so tumultuous as a new systems programming language.
The general spike in interest from 2021 onwards (the language has been around for a while so it's not like people just found out) is due to a large hangover from crypto folks who become jobless after the bust. Super savvy in general being online and evangelism. The safety stuff is overblown (small subset of applications primarily OS and browsers) and full rewrite is not possible or advisable.
This is the sort of thing I suspected without proof. It seems people do find that Rust is useful in terms of specific types of bugs but why cant pre C/C++ 11 just do the same job.
In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside the use of unsafe code).
In addition, you can't overflow a buffer nor unintentionally read outside the bounds of an array, that will cause a runtime panic and abort the program.
Doing this in C or C++ is possible, but the fact that even the best of the best programmers in these languages sometimes still make these mistakes shows the limitations of the paradigm.
Even the most novice Rust programmer who stays in the guardrails will produce programs free of these sorts of memory safety bugs. The same cannot be said about C or C++ programs.
> In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside the use of unsafe code).
Aren't most of these issues caught in C++ code by static code analysis tools, and even just flipping switches on C++ compilers? I mean, check out tools like cppcheck and address sanitizer. They exist for ages.
Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys.
> Even the most novice Rust programmer who stays in the guardrails
I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. I’ve no experience with either language and I can safely say I’d have no idea which switches to “just flip” in the compiler and what tools I should look up to write safe C++ code.
I do know that “Learn Language X” books do not include this information so as to not overwhelm the novice.
> I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book.
That blend of comments is at best grasping at straws. How long do you think a developer stays a "novice"? Does Rust have any problem that prevents developers from learning and improving their skills as fast as any other developers do? Are all Rust projects maintained by novice and junior devs where no one at all can claim to have any senior level skills?
If that's the best argument, that's not an argument at all.
> Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys.
That is a strange takeaway from my post. Of course people care, but the difference is that one language and its toolchain was designed and built specifically to avoid these bugs and one wasn't.
I have been writing C++ professionally since around 2000-2001, and have been working with Rust for about 18 months. For single threaded code, the code I write in both is about equivalent in terms of robustness and stability, but for anything multithreaded, I trust my Rust code's correctness substantially more, even with all the checkers and sanitizers enabled on my C++ codebase.
Would I choose Rust for everything? Hell no, for evolutionary and fast moving code bases like in games, C++ is plenty good enough.
For anything systems related that requires parallelism and robustness, I will 100% stick with Rust.
> That is a strange takeaway from my post. Of course people care, but the difference is that one language and its toolchain was designed and built specifically to avoid these bugs and one wasn't.
That's specious reasoning, as it ignores facts such as a) mainstream compilers provide support to detect and throw warnings/errors for some of these issues, b) there are a myriad of de-facto standard tools that also detect and help prevent these issues.
So your blend of argument depends on purposely ignoring mundane solutions to typical issues. I mean, does anyone complain about C# using external static code analyzers to address and prevent issues? Would those only count if the were built into a language?
It is entirely unclear to me what point you are trying to make. Is your mundane solution to just add more sanitization and analysis to C and C++? If so, that's great, more safety in any language is fantastic. My issue with that is that it is an optional addition to the language rather than the default behavior.
The point I am making is that safe Rust _by default_ straight up disallows compiling code that has the potential for the vast majority of memory safety issues. Code with those issues is just a plain invalid program, and will not compile. If you want to bypass those protections, you need to explicitly opt-in with the unsafe keyword.
C or C++ code with the same issues is perfectly valid, will compile and run, but it has the potential to be incorrect. You can (and should!) bolt on tools to fix that, but the issue is that the language allows that behavior by default. Until these tools are the defaults, the problem is only partially solved - you have to opt-in to a large chunk of safety features, and even if you do, you get fewer of them to boot.
I'm not saying you should use Rust by any means. If you like C++, continue using it. But the fact here is that Rust solves a bunch of problems here and now today that C and C++ cannot, so it is baffling to me that people have such a visceral negative reaction to it.
>The next article in this series will look at the design of the interface between the C and Rust code in the kernel, as well as the process of adding new bindings when necessary.
This is the actual useful one since so little of the kernel has Rust bindings. When I tried to implement a filesystem driver in rust I spent most of my time trying to write bindings instead of trying to write a filesystem.
There are projects that make more sense:
https://arxiv.org/abs/2506.03876
https://github.com/asterinas/asterinas
The reasons we encounter pattern issues forcing Linux into a polyglot is not a new phenomena:
https://en.wikipedia.org/wiki/Second-system_effect
Best regards =3
sudo sudo
is this about sudo?
no
hmmm
I'm curious, who's driving the interest in Rust. Do people learn it in CS degree's and thats all they know? Do orgs like it as a language because its considered safer in the sense that there are usually less bugs compared to C++ (and hence get it introduced into CS degrees)? Is it that C++ has become an abomination over time with added features? Cant we just use C++ as C with polymorphism and encapsulation? Is it generics that are the sticking point (and people don't like STL)? Or is it simply that a new gen just want to have their own thing to differentiate themselves from the oldies... its more cool.
I personally invested a lot of time and effort into learning C/C++ and the only new language with enough difference to come along that was worth learning was Python imho. Not sure what significant differences Rust brings that warrant throwing all that knowledge away and starting again.
My interest in Rust comes from getting frustrated with C's type system. Rust has such a nice type system and I really enjoy the ownership semantics around concurrency. I think that C++ written "correctly" looks a lot like Rust and libkj [1] encourages this, but it is not enforced by the language.
[1] https://github.com/capnproto/capnproto/blob/v2/kjdoc/tour.md
Rust (without use of `unsafe`) eliminates several entire classes of bugs (including bugs that comprise the majority of security related memory safety issues) while providing performance comparable to C/C++.
That is really all there is to it - it is just the better option for systems programming by almost all available metrics, and I say this as someone who has been coding C and C++ professionally for coming up on 25 years.
Cool, but so does Java. So why Rust advertising specifically?
Safe Rust is actually safer than Java because Java still has data races (that happen when you don't use correct synchronization when doing multithreaded code). In Java data races aren't as catastrophic as C (that is, it's not UB), but they are still a very severe kind of bug.
In Safe Rust, data races can't happen because you can only share stuff between threads if they are either synchronized or read only - attempting to share data that can't be accessed by many threads results in a compile time error.
Also: Java depends heavily on the GC to have memory safety. There are probably some kernels that manage memory with GCs, but for most of them it's not appropriate.
Java does not provide performance comparable to C/C++.
- Java's use of GC and a large runtime makes it inappropriate for many use cases
- Java had a pretty slow startup time, which makes it a poor fit for many CLI applications and similar
- Java has historically had pretty poor support for interoperating with c libraries (although this is improving with project panama)
- Rust has a richer, more powerful type system than Java (although scala's is more comparable)
- Rust's affine types (lifetimes) actually prevent certain types of bugs that occur in languages like Java as well. Things like using a connection or file handle after it is closed, forgetting to release a lock, not properly synchronizing access to memory between multiple threads, etc.
Because adopting a language the utilizes a garbage collector for memory management in the Linux kernel is even less likely than adopting Rust.
One reason I can think of is its memory management model gives programmers more control than a garbage collector. With the borrow checker, you know when your variables will get dropped/deallocated, but a garbage collector is not necessarily as controllable.
Rust is interesting because it's the first language to really try to compete in the same space as C and C++ in quite a long time. Part of being a newer language is that it doesn't have to work around the baggage of horribly bad past decisions (e.g., null-terminated strings, or implicit integer promotion). Part of it is also that it can adopt newer language features (e.g., structured binding or pattern matching) and have it mesh well with the language rather than having some weird workarounds.
For many people, the most interesting aspect of Rust is that it builds into its type system a set of rules that makes it much more practical to avoid memory safety issues or concurrency issues--lifetimes and Send/Sync are an absolute godsend for such programming, especially because it means you get the compiler to kick you in the face when you screw it up. Rather famously, Mozilla attempted a couple of parallel layout engines in C++ but their attempts all failed, because it just wasn't feasible to shake out all of the concurrency issues; their first attempt at doing so in Rust had none of those issues. It's not that the rules are complicated or hard to follow, it's that in large codebases, the invariants you need to uphold are described only in comments and can be easy to forget.
Thanks for that perspective.
As a person that occasionally daytrips into Rust and Zig, I'd imagine some number of us are coming from higher level languages (JS/TS, Python, etc) as our daily drivers and interested in what performance we could get closer to the metal.
In those cases we don't have a particular investment in C/C++, we don't know the differences between gcc or clang, we are used to package managers, don't manage header files, and things like comfy error messages and "if it compiles it's reasonably safe tm" are better than... Not having those things.
Meanwhile, outside of things like CUDA interop I don't know what the compelling case for C/C++ even is for someone who isn't invested.
Most of the interest I have seen is in pursuit of security. A few sources have cited that something like 70% of vulnerabilities are rooted in memory safety issues.
A language that makes it impossible to introduce 70% of the security bugs is appealing.
Java does not have memory safety issues. But it's not appealing, apparently.
So why Rust then?
Memory safe languages such as Java have already taken the world by storm, decades ago.
The interesting combination rust brings is a memory safe language that can compete with C and C++ for the speed crown.
Java is not a systems level programming language (at least in its modern OpenJDK form)
Sun tried out allowing Java in the kernel, it could be used to write device drivers just as Rust is being used now.
I think it aims to have the features of C++ that are required for modern safe systems programming, but not all the baggage that comes with such a large and historied language.
i didnt know that it had been introduced in colleges
when did that happen?
i thought it would take a long time for colleges to include rust as it has a high learning curve
I dont know either, thats what I'm trying to figure out.
> Not sure what significant differences Rust brings that warrant throwing all that knowledge away and starting again
This is not how learning programming languages works
Rust has more and nicer language features compared to c++ that you can use to make the code readable.
I wish rust had overloading and specialization though.
> I personally invested a lot of time and effort into learning C/C++ and the only new language with enough difference to come along that was worth learning was Python imho. Not sure what significant differences Rust brings that warrant throwing all that knowledge away and starting again.
Ive written a little c++ professionally along with rust. I really don't think rust is that hard to learn. Especially compared to c++, I'd be embarrassed to tell people i "know" c++ despite using it a bit. there's so much to writing c++.
I think you would be a competent rust programmer in a couple weeks, have a pretty good grasp on the language and be able to pretty much contribute to any in progress project.
You could spend a weekend going through the rust book and have a good idea of the language. I dont think I could say that to anyone about any c++ book lol
I mean I don't mind learning it if it solves problems and is reasonably enjoyable to program in (which I find C/C++ to be) but the rebel in me doesn't want to conform to what big business/politics wants I guess. I know thats a terrible metric to use in this field.
How does the rebel square itself with the fact of using big business/politics mandated C++?
I think it's the rust folk who are the rebels. Status quo types would never advocate for something so tumultuous as a new systems programming language.
The general spike in interest from 2021 onwards (the language has been around for a while so it's not like people just found out) is due to a large hangover from crypto folks who become jobless after the bust. Super savvy in general being online and evangelism. The safety stuff is overblown (small subset of applications primarily OS and browsers) and full rewrite is not possible or advisable.
This is the sort of thing I suspected without proof. It seems people do find that Rust is useful in terms of specific types of bugs but why cant pre C/C++ 11 just do the same job.
In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside the use of unsafe code).
In addition, you can't overflow a buffer nor unintentionally read outside the bounds of an array, that will cause a runtime panic and abort the program.
Doing this in C or C++ is possible, but the fact that even the best of the best programmers in these languages sometimes still make these mistakes shows the limitations of the paradigm.
Even the most novice Rust programmer who stays in the guardrails will produce programs free of these sorts of memory safety bugs. The same cannot be said about C or C++ programs.
> In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside the use of unsafe code).
Aren't most of these issues caught in C++ code by static code analysis tools, and even just flipping switches on C++ compilers? I mean, check out tools like cppcheck and address sanitizer. They exist for ages.
Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys.
> Even the most novice Rust programmer who stays in the guardrails
I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. I’ve no experience with either language and I can safely say I’d have no idea which switches to “just flip” in the compiler and what tools I should look up to write safe C++ code.
I do know that “Learn Language X” books do not include this information so as to not overwhelm the novice.
> I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book.
That blend of comments is at best grasping at straws. How long do you think a developer stays a "novice"? Does Rust have any problem that prevents developers from learning and improving their skills as fast as any other developers do? Are all Rust projects maintained by novice and junior devs where no one at all can claim to have any senior level skills?
If that's the best argument, that's not an argument at all.
> Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys.
That is a strange takeaway from my post. Of course people care, but the difference is that one language and its toolchain was designed and built specifically to avoid these bugs and one wasn't.
I have been writing C++ professionally since around 2000-2001, and have been working with Rust for about 18 months. For single threaded code, the code I write in both is about equivalent in terms of robustness and stability, but for anything multithreaded, I trust my Rust code's correctness substantially more, even with all the checkers and sanitizers enabled on my C++ codebase.
Would I choose Rust for everything? Hell no, for evolutionary and fast moving code bases like in games, C++ is plenty good enough.
For anything systems related that requires parallelism and robustness, I will 100% stick with Rust.
> That is a strange takeaway from my post. Of course people care, but the difference is that one language and its toolchain was designed and built specifically to avoid these bugs and one wasn't.
That's specious reasoning, as it ignores facts such as a) mainstream compilers provide support to detect and throw warnings/errors for some of these issues, b) there are a myriad of de-facto standard tools that also detect and help prevent these issues.
So your blend of argument depends on purposely ignoring mundane solutions to typical issues. I mean, does anyone complain about C# using external static code analyzers to address and prevent issues? Would those only count if the were built into a language?
It is entirely unclear to me what point you are trying to make. Is your mundane solution to just add more sanitization and analysis to C and C++? If so, that's great, more safety in any language is fantastic. My issue with that is that it is an optional addition to the language rather than the default behavior.
The point I am making is that safe Rust _by default_ straight up disallows compiling code that has the potential for the vast majority of memory safety issues. Code with those issues is just a plain invalid program, and will not compile. If you want to bypass those protections, you need to explicitly opt-in with the unsafe keyword.
C or C++ code with the same issues is perfectly valid, will compile and run, but it has the potential to be incorrect. You can (and should!) bolt on tools to fix that, but the issue is that the language allows that behavior by default. Until these tools are the defaults, the problem is only partially solved - you have to opt-in to a large chunk of safety features, and even if you do, you get fewer of them to boot.
I'm not saying you should use Rust by any means. If you like C++, continue using it. But the fact here is that Rust solves a bunch of problems here and now today that C and C++ cannot, so it is baffling to me that people have such a visceral negative reaction to it.
Presumably because decades of experience has shown that it doesn't. Also insofar as avoiding certain pervasive security issues it can't.
> Presumably because decades of experience has shown that it doesn't.
What definition of "doesn't" do you adhere to? Because there are use-after-free CVEs from Rust code.
https://nvd.nist.gov/vuln/detail/CVE-2025-48752
[dead]