The rust driver does read better. I like that the functions are organized as methods under a member less struct, as opposed to the C version where they are top level with_really_long_function_names that take a struct parameter.
Some drivers written in Rust instead of C would need to be littered with unsafes, raw pointers, pointer arithmetic, manual memory management, manual layout control, and manual resource management to retain similar behaviors. I’m assuming someone’s ideal would be for the entire kernel to be rewritten in Rust? When all that is said and done, will it be worth the effort? It’d seem as though you’d have a lot of the same problems, and new ones around timing and performance if you start handling memory differently, like jitteriness, lags, OOM (letting resource usage get out-of-hand), lock-ups, or worse, unless it’s well-tested. I have nothing against Rust, and writing new drivers in Rust selectively would be fine, but I could see it going this way and am curious. To be absolutely clear, Rust is not bad; I just wonder about introducing complexity in maintenance of the kernel by having variation in memory management, because I’d almost rather have a diagnosable memory leak that’s well-tested for than “I have no idea what’s going on.”
> Some drivers written in Rust instead of C would need to be littered with unsafes, raw pointers, pointer arithmetic,
The main safety benefit of Rust in a low-level environment is not that you never have to write unsafe code; it's that the language allows you to encapsulate unsafe code and express its safety invariants in the type system. My go-to example of this is the Vec type in the standard library. The language doesn't have any notion of a growable array built-in; it's defined in pure Rust code in the standard library using some unsafe code that exposes a fully safe API. And using the invariants expressed in that API, the compiler can prove the safety of any user code that uses a growable array, under the axiom that the unsafe definition of Vec was correct.
The standard library is rich enough that application developers never really have to touch unsafe, and that's great for them -- but for those of us doing systems programming, this "axiomatic safety" (as I like to think of it) is the real power of Rust. We can do complicated and unsafe things (like direct hardware access, complicated pointer tricks, concurrent data structures, etc.), write out the invariants users need to uphold in order for the code to be sound, and then the compiler can prove the program safe under the assumption that our unsafe building blocks are sound. Well-written Rust isn't "littered with unsafes" everywhere; the unsafe code only appears in low-level definitions of data structures and hardware/foreign function interfaces, and the rest of the code is written in safe Rust.
> manual memory management, manual layout control, and manual resource management to retain similar behaviors.
All of these things are manual in Rust. There's no GC and the compiler does not insert allocations or deallocations; it's all done by user or library code. Layout is entirely controlled by the programmer (the compiler does optimize struct layout by default, but you can opt out by marking the struct #[repr(C)]).
Rust is not garbage collected, and there is no automatic memory management of any kind. The philosophy is: you manage memory manually, and the compiler checks your work to make sure you didn't make a mistake. The only real difference from C (besides the safety guarantees) is that Rust has destructors, so you can use RAII to simplify cleanup/freeing.
For what it’s worth, the Rust driver pointed to in the article doesn’t have a single unsafe block, raw pointer, pointer arithmetic, or any of those other things you mentioned.
It’s a simple driver. But it’s also possible that rust code doesn’t necessarily have to copy the C code line for line - the C way of doing things with pointer arithmetic may just not be necessary with the abstractions rust provides.
In Rust you know there is no memory issue because there is no unsafe block. In C you don't know if there is no memory issue, there are many way to write a hello world that has memory issue.
char hello[5] = "Hello";
Oops, forgot the \0, memory issue when printing that string.
Even complex driver in rust will have very little amount of unsafe because of correct use of (often zero cost) abstractions. And it is much less mental drain to check only that, than when every single line is a minefield that could hide undefined behavior
> Some drivers written in Rust instead of C would need to be littered with unsafes, raw pointers, pointer arithmetic, manual memory management, manual layout control, and manual resource management to retain similar behaviors.
Some might, the extent remains to be seen. Of course there needs to be code that has unsafe memory management, but a small amount of very well checked code that creates safe wrappers can eliminate the possibility of bad memory handling in huge chunks of the remaining logic. It doesn't eliminate the errors 100% of course, and that's OK - reducing the quantity, search space, and even possibility of a lot of bugs is still a good thing, as it means correctness can be acheived with less time and effort.
> I’m assuming the goal is to have the entire kernel rewritten in Rust.
Who's goal? Some people may want to see that sure. Plenty of others are happy just because this experiment is allowing Rust itself to improve as the r4l people are effectively pushing rust into territory it hasn't been used in previously. Some people just want to see rust in drivers since they are often a pain to keep porting around as internal kernel apis change, and having safe rust abstractions around the tricky bits makes that porting effort much easier.
> Because you’ll have a lot of the same problems, and it seems you could introduce new ones around timing and performance if you start handling memory differently.
If you have a driver so sensitive to timing and performance that a small amount of memory handling change can break it - you'll have these issues whenever the C code around memory management changes as well. There are regularly changes to memory allocation, scheduling, etc within the kernel anyway, so I think this concept is a bit of a moot concern.
>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.
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.
And even for projects that are written in a language that uses a GC (like written in Python, or Java, or C#), having two GCs in the same project, sharing data between each other, is kind of catastrophic. Because of this, a project in a high level language either uses libraries written in the same language (or at least the same runtime), or languages written in C or C++. So Python programs use Python libraries or C libraries, C# programs use C#/.NET libraries or C libraries. But it's uncommon to use a Python library in a C# project, or a C# library in a Python project.
Just like C, Rust fills the niche of writing libraries that can be used in many ecosystems. Right now some Rust libraries are used in Javascript projects (either on node or on the web, with wasm), for example.
- 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.
It depends on what you call "performance". IO throughput can be the same. So can be CPU utilization. Memory consumption will always be larger though, and the kind of code you need to write in Java to achieve parity might not look like any Java most people are familiar with.
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 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.
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.
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.
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
Majority of cpp knowledge is not universal computer science, but cpp's quirks, issues, tricks, hacks and wasted life fighting lack of coherent building system and package manager alongside of long compile times
This is a very important point if the tool is used by millions of people. All you need to do is waste a few 10s of seconds with some weird quirk that doesn’t act as expected, and BAM, collectively easily a year of human life was wasted.
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 have actually been a proponent for Rust as First Language at the university I work for. However today our first year CS students are taught Python as their First Language, with I believe an option to learn Rust among others much later.
The two most important/ prestigious universities here, Oxford and Cambridge as I understand it both teach an ML as First Language, teaching Rust would arguably qualify (Rust is basically an ML but with spelling familiar to a C or Java programmer) but with the caveat that one reason they teach an ML first (and indeed so did the place where I got my degree) is that some of the 18 year olds in your class know C or Java or indeed Python, but they almost certainly do not know Ocaml or SML or whatever - whereas they might know Rust.
And that sort of gets to where your parent was thinking. On the whole it's not that university (or "college") teaches Rust, but that because Rust is a good first language some people will have just acquired Rust anyway. I came to Rust as somebody with decades of C and Java and some Python, Go, and a long list of languages, but today plenty of learners just pick up Rust themselves.
I do not even have CS degree or programming background. But Rust seemed easier to learn than C or C++. Well I've learned C syntax in a day but really using it is different story. Rust gave me confidence to contribute to existing (open-source) project pretty early.
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.
No, they aren't. C++ codebases, even those who make quite a big effort to use as many analysers and checkers and sanitizers as they can, are still plagued by memory safety issues. Rust has a measurably lower incidence of security bugs due to this (not zero, but lower). People have tried (and are still trying) to retrofit memory safety onto C++ and they have not in general been successful. There's too many sharp edges built into the current language and library design, and these tools cannot catch all the ways in which you can mess up.
(What's more, Rust is substantially nicer to use than C++. The language, package manager, and compiler are all so much more straightforward than C++ that I would use it for that alone)
> 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.
> 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.
Look, I’m not the one making these arguments, I’m just pointing out that all your objections seem to have been answered already. If you have a counter argument that shows Rust, as practiced, is no safer than C++, then I’d like to see it.
> 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.
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.
> mainstream compilers provide support to detect and throw warnings/errors for some of these issues
You cannot detect all of these issues with static analysis. Rust does it by requiring the programmer to annotate lifetime dependencies in the source code. Without this additional semantic information, static analysis cannot fully reason about the lifetimes of variables.
There are efforts by some to introduce lifetime annotations to C++ (https://news.ycombinator.com/item?id=30888172), but any changes to the core language face a very steep uphill battle with the C++ standards committee, so any movement on this is likely to be compiler-specific attribute-based systems, adopted largely by companies invested in a particular compiler ecosystem (such as Apple or Google) to annotate their proprietary code.
On top of this, Rust is a very expressive language, with its features (like enum sum-types, traits etc) making it very easy to implement patterns such as compiler-checked state machines and polymorphism that doesn't involve the recognized downsides of class hierarchies.
It is not for everyone, and not for every kind of project, but its features resonate positively with a lot of people in systems programming because of their experiences with other systems languages and their downsides.
This is why Rust is popular today, particularly in certain communities.
> You are claiming that static code analysis tools extensively used in C++ cannot detect all conceivable and hypothetical memory issues. The weasel words in here is that it is possible to detect them, but some can conceivably slip through.
No, there are entire classes of memory vulnerabilities that are impossible to check with static analysis because checking them is equivalent to the halting problem.
> To drive the point home, there are already a few CVEs even from use-after-free bugs in Rust code. What does that make out of the all assertion? Would this be a reasonable argument to reject Rust as an unsafe language?
The CVE that you referenced in the other comment was Rust calling into unsafe C code, as I pointed out. If you have a real example feel free to post it.
> The problem with these claims is that they rely on weak strawmen arguments and a very superficial analysis of the problem space. I get the need to do marketing, but if the audience is technical them don't you think arguments should stand on solid technical ground?
The views I have laid out here are the consensus among compiler engineers and in theoretical computer science. You only have to look at the compiler group at Apple:
- heavily invested in static analysis
- maintains the clang static analyzer
- maintains number of runtime memory analysis tools in Xcode
- not invested in rust at all and seemingly not interested
The reason for this is that static analysis simply cannot do it when the semantic information about lifetimes is lost, even for a group that knows how to write strong static analysis tools. Program flow is too ambiguous without it, so it becomes impossible to detect such memory vulnerabilities without running the program and fuzzing it – an expensive, time consuming, and probabilistic process.
> No, there are entire classes of memory vulnerabilities that are impossible to check with static analysis because checking them is equivalent to the halting problem.
This is the sort of goalpost-moving that lays bare how superficial and misleading these accusations are. You're trying to argue that some very specific types of memory vulnerabilities can't be detected with static code analysis tools. That is different than claiming that it's not possible to detect memory vulnerabilities in languages such as C or C++, isn't it? But somehow this strawman is used to imply that Rust is invulnerable whereas developers using any other language are prevented from ever learning that standard FLOSS compilers support out of the box things such as detecting use of uninitialized variables.
This is not a very good example, because this Rust code is a thin wrapper around pthread_mutex, which is an unsafe API that can cause undefined behavior (such as use after free) if used incorrectly. The Rust code in question is using the unsafe C API incorrectly.
One could say "Rust doesn't stop you from calling out into unsafe C code, so it's still possible to produce memory vulnerabilities in Rust", and it would be true, but it kind of misses the point and only really bolsters the Rust people when they say they want to rewrite everything in Rust.
In Rust, an API with a rule such as "you must check that the mutex is unlocked before you can destroy it" would be implemented using the type system in such a way as to make it impossible to drop it without checking its state. This is something that is not possible to do in C and cumbersome to do in C++.
There are a few interesting trends in that list. One of them is that there's an increasing amount of Rust. People are going to write many of the high level bugs (e.g. logic mistakes) in any language, but if they're not using your language they won't write any in your language. Lots are written in Rust.
But another is that the kind of things even reported is different. There's a case a while back where C++ and Rust have identical APIs which make an identical promise. The obvious way to implement that API on popular platforms introduces a TOCTOU race, and so that race was present in Rust's stdlib and in all three popular C++ standard library implementations. Rust reported the TOCTOU race and its fix, there's a CVE number. The three C++ libraries just decided it's a QOI issue and silently made equivalent changes over the next few months or years.
In C++ the argument goes like this: C++ says that if any other programs are running on your computer, all filesystem access is Undefined Behaviour. Simply do not run more than one program per computer, then there's no TOCTOU race, no bug. Rust says duh, obviously multi-processing has been a thing since the 1960s so we have to assume other programs may be running, the TOCTOU race is a bug and must be fixed.
The rust driver does read better. I like that the functions are organized as methods under a member less struct, as opposed to the C version where they are top level with_really_long_function_names that take a struct parameter.
Absolutely! Organization is extremely important!
Some drivers written in Rust instead of C would need to be littered with unsafes, raw pointers, pointer arithmetic, manual memory management, manual layout control, and manual resource management to retain similar behaviors. I’m assuming someone’s ideal would be for the entire kernel to be rewritten in Rust? When all that is said and done, will it be worth the effort? It’d seem as though you’d have a lot of the same problems, and new ones around timing and performance if you start handling memory differently, like jitteriness, lags, OOM (letting resource usage get out-of-hand), lock-ups, or worse, unless it’s well-tested. I have nothing against Rust, and writing new drivers in Rust selectively would be fine, but I could see it going this way and am curious. To be absolutely clear, Rust is not bad; I just wonder about introducing complexity in maintenance of the kernel by having variation in memory management, because I’d almost rather have a diagnosable memory leak that’s well-tested for than “I have no idea what’s going on.”
> Some drivers written in Rust instead of C would need to be littered with unsafes, raw pointers, pointer arithmetic,
The main safety benefit of Rust in a low-level environment is not that you never have to write unsafe code; it's that the language allows you to encapsulate unsafe code and express its safety invariants in the type system. My go-to example of this is the Vec type in the standard library. The language doesn't have any notion of a growable array built-in; it's defined in pure Rust code in the standard library using some unsafe code that exposes a fully safe API. And using the invariants expressed in that API, the compiler can prove the safety of any user code that uses a growable array, under the axiom that the unsafe definition of Vec was correct.
The standard library is rich enough that application developers never really have to touch unsafe, and that's great for them -- but for those of us doing systems programming, this "axiomatic safety" (as I like to think of it) is the real power of Rust. We can do complicated and unsafe things (like direct hardware access, complicated pointer tricks, concurrent data structures, etc.), write out the invariants users need to uphold in order for the code to be sound, and then the compiler can prove the program safe under the assumption that our unsafe building blocks are sound. Well-written Rust isn't "littered with unsafes" everywhere; the unsafe code only appears in low-level definitions of data structures and hardware/foreign function interfaces, and the rest of the code is written in safe Rust.
> manual memory management, manual layout control, and manual resource management to retain similar behaviors.
All of these things are manual in Rust. There's no GC and the compiler does not insert allocations or deallocations; it's all done by user or library code. Layout is entirely controlled by the programmer (the compiler does optimize struct layout by default, but you can opt out by marking the struct #[repr(C)]).
Rust is not garbage collected, and there is no automatic memory management of any kind. The philosophy is: you manage memory manually, and the compiler checks your work to make sure you didn't make a mistake. The only real difference from C (besides the safety guarantees) is that Rust has destructors, so you can use RAII to simplify cleanup/freeing.
For what it’s worth, the Rust driver pointed to in the article doesn’t have a single unsafe block, raw pointer, pointer arithmetic, or any of those other things you mentioned.
It’s a simple driver. But it’s also possible that rust code doesn’t necessarily have to copy the C code line for line - the C way of doing things with pointer arithmetic may just not be necessary with the abstractions rust provides.
It's basically a "Hello, World" type of driver. A "Hello, World" in C or Rust typically also doesn't involve unsafe blocks or safety issues.
In Rust you know there is no memory issue because there is no unsafe block. In C you don't know if there is no memory issue, there are many way to write a hello world that has memory issue.
Oops, forgot the \0, memory issue when printing that string.Even complex driver in rust will have very little amount of unsafe because of correct use of (often zero cost) abstractions. And it is much less mental drain to check only that, than when every single line is a minefield that could hide undefined behavior
> Some drivers written in Rust instead of C would need to be littered with unsafes, raw pointers, pointer arithmetic, manual memory management, manual layout control, and manual resource management to retain similar behaviors.
Some might, the extent remains to be seen. Of course there needs to be code that has unsafe memory management, but a small amount of very well checked code that creates safe wrappers can eliminate the possibility of bad memory handling in huge chunks of the remaining logic. It doesn't eliminate the errors 100% of course, and that's OK - reducing the quantity, search space, and even possibility of a lot of bugs is still a good thing, as it means correctness can be acheived with less time and effort.
> I’m assuming the goal is to have the entire kernel rewritten in Rust.
Who's goal? Some people may want to see that sure. Plenty of others are happy just because this experiment is allowing Rust itself to improve as the r4l people are effectively pushing rust into territory it hasn't been used in previously. Some people just want to see rust in drivers since they are often a pain to keep porting around as internal kernel apis change, and having safe rust abstractions around the tricky bits makes that porting effort much easier.
> Because you’ll have a lot of the same problems, and it seems you could introduce new ones around timing and performance if you start handling memory differently.
If you have a driver so sensitive to timing and performance that a small amount of memory handling change can break it - you'll have these issues whenever the C code around memory management changes as well. There are regularly changes to memory allocation, scheduling, etc within the kernel anyway, so I think this concept is a bit of a moot concern.
>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.
Did you try bindgen? Because it’s extremely good and efficient imo.
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
[flagged]
[flagged]
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.
And even for projects that are written in a language that uses a GC (like written in Python, or Java, or C#), having two GCs in the same project, sharing data between each other, is kind of catastrophic. Because of this, a project in a high level language either uses libraries written in the same language (or at least the same runtime), or languages written in C or C++. So Python programs use Python libraries or C libraries, C# programs use C#/.NET libraries or C libraries. But it's uncommon to use a Python library in a C# project, or a C# library in a Python project.
Just like C, Rust fills the niche of writing libraries that can be used in many ecosystems. Right now some Rust libraries are used in Javascript projects (either on node or on the web, with wasm), for example.
- 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 that 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.
Java does not provide performance comparable to C/C++.
It depends on what you call "performance". IO throughput can be the same. So can be CPU utilization. Memory consumption will always be larger though, and the kind of code you need to write in Java to achieve parity might not look like any Java most people are familiar with.
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 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.
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.
You can hammer an applications programming language to do systems things, but it will never be a good experience nor have optimal performance.
This [1] was the paper on it.
[1] https://labs.oracle.com/pls/apex/f?p=LABS:0:3891254133275:AP...
Could you write interrupt handlers in it? You can't even do synchronous signal handling in Java.
How would that even work with the JVM?
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.
> 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
You are correct, but its still a fair bit of effort and muscle memory that needs to be developed, I'm trying to figure out if the payoff is worth it.
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
Majority of cpp knowledge is not universal computer science, but cpp's quirks, issues, tricks, hacks and wasted life fighting lack of coherent building system and package manager alongside of long compile times
> quirks, issues, tricks, hacks and wasted life
This is a very important point if the tool is used by millions of people. All you need to do is waste a few 10s of seconds with some weird quirk that doesn’t act as expected, and BAM, collectively easily a year of human life was wasted.
Avoid surprising behavior.
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 have actually been a proponent for Rust as First Language at the university I work for. However today our first year CS students are taught Python as their First Language, with I believe an option to learn Rust among others much later.
The two most important/ prestigious universities here, Oxford and Cambridge as I understand it both teach an ML as First Language, teaching Rust would arguably qualify (Rust is basically an ML but with spelling familiar to a C or Java programmer) but with the caveat that one reason they teach an ML first (and indeed so did the place where I got my degree) is that some of the 18 year olds in your class know C or Java or indeed Python, but they almost certainly do not know Ocaml or SML or whatever - whereas they might know Rust.
And that sort of gets to where your parent was thinking. On the whole it's not that university (or "college") teaches Rust, but that because Rust is a good first language some people will have just acquired Rust anyway. I came to Rust as somebody with decades of C and Java and some Python, Go, and a long list of languages, but today plenty of learners just pick up Rust themselves.
I dont know either, thats what I'm trying to figure out.
I do not even have CS degree or programming background. But Rust seemed easier to learn than C or C++. Well I've learned C syntax in a day but really using it is different story. Rust gave me confidence to contribute to existing (open-source) project pretty early.
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.
No, they aren't. C++ codebases, even those who make quite a big effort to use as many analysers and checkers and sanitizers as they can, are still plagued by memory safety issues. Rust has a measurably lower incidence of security bugs due to this (not zero, but lower). People have tried (and are still trying) to retrofit memory safety onto C++ and they have not in general been successful. There's too many sharp edges built into the current language and library design, and these tools cannot catch all the ways in which you can mess up.
(What's more, Rust is substantially nicer to use than C++. The language, package manager, and compiler are all so much more straightforward than C++ that I would use it for that alone)
> 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.
> 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.
Look, I’m not the one making these arguments, I’m just pointing out that all your objections seem to have been answered already. If you have a counter argument that shows Rust, as practiced, is no safer than C++, then I’d like to see it.
So why all the software is still so insecure?
[flagged]
> 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.
[flagged]
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.
[flagged]
> mainstream compilers provide support to detect and throw warnings/errors for some of these issues
You cannot detect all of these issues with static analysis. Rust does it by requiring the programmer to annotate lifetime dependencies in the source code. Without this additional semantic information, static analysis cannot fully reason about the lifetimes of variables.
There are efforts by some to introduce lifetime annotations to C++ (https://news.ycombinator.com/item?id=30888172), but any changes to the core language face a very steep uphill battle with the C++ standards committee, so any movement on this is likely to be compiler-specific attribute-based systems, adopted largely by companies invested in a particular compiler ecosystem (such as Apple or Google) to annotate their proprietary code.
On top of this, Rust is a very expressive language, with its features (like enum sum-types, traits etc) making it very easy to implement patterns such as compiler-checked state machines and polymorphism that doesn't involve the recognized downsides of class hierarchies.
It is not for everyone, and not for every kind of project, but its features resonate positively with a lot of people in systems programming because of their experiences with other systems languages and their downsides.
This is why Rust is popular today, particularly in certain communities.
[flagged]
Replying to your other comment.
> You are claiming that static code analysis tools extensively used in C++ cannot detect all conceivable and hypothetical memory issues. The weasel words in here is that it is possible to detect them, but some can conceivably slip through.
No, there are entire classes of memory vulnerabilities that are impossible to check with static analysis because checking them is equivalent to the halting problem.
> To drive the point home, there are already a few CVEs even from use-after-free bugs in Rust code. What does that make out of the all assertion? Would this be a reasonable argument to reject Rust as an unsafe language?
The CVE that you referenced in the other comment was Rust calling into unsafe C code, as I pointed out. If you have a real example feel free to post it.
> The problem with these claims is that they rely on weak strawmen arguments and a very superficial analysis of the problem space. I get the need to do marketing, but if the audience is technical them don't you think arguments should stand on solid technical ground?
The views I have laid out here are the consensus among compiler engineers and in theoretical computer science. You only have to look at the compiler group at Apple:
- heavily invested in static analysis - maintains the clang static analyzer - maintains number of runtime memory analysis tools in Xcode - not invested in rust at all and seemingly not interested
Yet they are adding lifetime dependency annotations to Swift, making it more like Rust: https://github.com/swiftlang/swift-evolution/blob/ef71df4158...
The reason for this is that static analysis simply cannot do it when the semantic information about lifetimes is lost, even for a group that knows how to write strong static analysis tools. Program flow is too ambiguous without it, so it becomes impossible to detect such memory vulnerabilities without running the program and fuzzing it – an expensive, time consuming, and probabilistic process.
> No, there are entire classes of memory vulnerabilities that are impossible to check with static analysis because checking them is equivalent to the halting problem.
This is the sort of goalpost-moving that lays bare how superficial and misleading these accusations are. You're trying to argue that some very specific types of memory vulnerabilities can't be detected with static code analysis tools. That is different than claiming that it's not possible to detect memory vulnerabilities in languages such as C or C++, isn't it? But somehow this strawman is used to imply that Rust is invulnerable whereas developers using any other language are prevented from ever learning that standard FLOSS compilers support out of the box things such as detecting use of uninitialized variables.
So what is it then?
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
This is not a very good example, because this Rust code is a thin wrapper around pthread_mutex, which is an unsafe API that can cause undefined behavior (such as use after free) if used incorrectly. The Rust code in question is using the unsafe C API incorrectly.
https://github.com/Forestryks/process-sync-rs/issues/3
One could say "Rust doesn't stop you from calling out into unsafe C code, so it's still possible to produce memory vulnerabilities in Rust", and it would be true, but it kind of misses the point and only really bolsters the Rust people when they say they want to rewrite everything in Rust.
In Rust, an API with a rule such as "you must check that the mutex is unlocked before you can destroy it" would be implemented using the type system in such a way as to make it impossible to drop it without checking its state. This is something that is not possible to do in C and cumbersome to do in C++.
> This is not a very good example
Feel free to pick an example that tickles your fancy.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
There are a few interesting trends in that list. One of them is that there's an increasing amount of Rust. People are going to write many of the high level bugs (e.g. logic mistakes) in any language, but if they're not using your language they won't write any in your language. Lots are written in Rust.
But another is that the kind of things even reported is different. There's a case a while back where C++ and Rust have identical APIs which make an identical promise. The obvious way to implement that API on popular platforms introduces a TOCTOU race, and so that race was present in Rust's stdlib and in all three popular C++ standard library implementations. Rust reported the TOCTOU race and its fix, there's a CVE number. The three C++ libraries just decided it's a QOI issue and silently made equivalent changes over the next few months or years.
In C++ the argument goes like this: C++ says that if any other programs are running on your computer, all filesystem access is Undefined Behaviour. Simply do not run more than one program per computer, then there's no TOCTOU race, no bug. Rust says duh, obviously multi-processing has been a thing since the 1960s so we have to assume other programs may be running, the TOCTOU race is a bug and must be fixed.
[dead]