As a "userspace" Rust developer, I'm happy that this still appears to be close enough to the standard Rust dialect that I could still be productive. I suspect that allocations are intentionally a little more explicit.
It would be cool if there was a few easy-for-beginner tasks to pick up and try my hand at this sort of work.
A big eventual non-technical goal of the Rust for Linux project is to reduce the barrier to entry for kernel programming, Rust is a good language for averting gumption traps IMO †
Why do I have a feeling that using Rust for such kind of low-level programming would actually make development less straightforward than when using C which was made specifically for that purpose? I mean, it's better to pick a right tool for a job, rather than try to push and shape a favourite tool which is better used in other scenarios.
> The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)
> Rust isn't a "silver bullet" that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going
forward, why wouldn't we want that?
I had my journey of using Rust to implement a WinAPI-based app in which I did lots of unsafe (from Rust's point of view) operations. I spent more time on fighting with Rust's protections than on the actual implementation. The result code wasn't safe and looked horrible - totally opposite of what Rust code should look like. And yes, I followed "the Rust way" of doing things.
As much as I really like the mechanics of Rust and the language itself, I don't think I'm gonna use it for any of the device drivers I'm working on.
The problems you have quoted are due to developers being sloppy. I've gone through hundreds of source codes in Kernel, and most of them wouldn't pass code review in my company - cutting-corners everywhere, multipurpose functions, lack of documentation; those are issues which can't be fixed by just changing a language. Sure it will protect developers from missing "free()" here and there, but it's gonna bite from another side.
> I had my journey of using Rust to implement a WinAPI-based app in which I did lots of unsafe (from Rust's point of view) operations. I spent more time on fighting with Rust's protections than on the actual implementation. The result code wasn't safe and looked horrible - totally opposite of what Rust code should look like. And yes, I followed "the Rust way" of doing things.
I hate to just directly question your last statement, but “tons of unsafe” is a red flag that the way things are being done. You should need it for direct interactions with a C API, or for the lowest level of interacting with bare metal memory registers, or for lowest level high performance code that’s verging on or actually using assembly.
I can see how doing windows API stuff would cause a lot of the FFI usage of unsafe, but that should be handled by the winapi or a windows api crate that converts things to idiomatic rust and the rest of the codebase would be dealing with logic.
Entirely possible you hit an edge case here where you were writing glue code which exclusively talked to hand-optimized SSE algorithms or something, but that is exceedingly rare compared to someone just starting out who’s experienced with C trying to do things the C way and fighting through unsafe rather than looking for and finding higher-level patterns that are idiomatic.
> I've gone through hundreds of source codes in Kernel, and most of them wouldn't pass code review in my company - cutting-corners everywhere, multipurpose functions, lack of documentation; those are issues which can't be fixed by just changing a language.
Except they are mitigated to such a degree that it again makes me doubt you were coding idiomatically.
Rust tends to force you to exhaustively handle code paths, so it will require a lot of explicit opting out to cut corners.
Type-safety tends to help a lot in making multipurpose functions self-verifying. Function chains come up a lot more in Rust and type inference works so well because of this.
Documentation is a lot easier when you can just have people use “cargo doc” and add a bit of markdown and some doctests that will get exercised by CI.
> Sure it will protect developers from missing "free()" here and there, but it's gonna bite from another side.
RAII is the smallest difference in DX in Rust compared to working in C. For me the biggest differences were tooling, and type-safety making it a lot easier to catch bugs at compile-time, and enforce design assumptions I had about the architecture.
I don’t necessarily expect it to be easier to write Rust code, but I do expect it will catch more issues up-front rather than at runtime or in the field, so you will end up doing more code-compile iterations (seconds to minutes) and fewer code-customer iterations (hours to days or weeks).
Though when it comes to C++, there is less surface area of the language to learn to get to the modern “safe” constructs and the constructs enforce their own proper usage rather than expecting the developer to, so I expect an intermediate developer to be writing better code until a C++ developer gets to an expert level.
when you say "i did lots of unsafe operations", i think it contractions the claim that you "followed the rust way of doing things".
what's the point of using a "memory-safe" language if you just gonna use unsafe blocks and ignore that? i agree with you point that there's some operations that rust sucks and c is a better option although. but my claim is that writing unsafe rust and safe are diferent things, for example they created a book talking just about unsafe rust -> https://doc.rust-lang.org/nomicon/
Can't count in years because for my 9-5 work I use different languages. I started learning C when I was 15, now I'm over 30, and it constantly appears somewhere in my life, whether this is embedded or desktop development. Kernel - occasionally, when I must adapt or implement a device driver. Rust - I had three approaches, all of them related to WinAPI-based programs, but didn't suit my needs. I like it, I will come back to it at some point for sure, but definitely not in the context of Kernel.
C really wasn't designed to handle common low-level hurdles any more than the CPUs that created the problems were. Just because you can formulate solutions doesn't mean shooting yourself in the foot isn't easier.
Applying the phrase "designed" to C is already dubious. It's a language that evolved from a very minimal and not terribly "designed" thing based off predecessor languages whose primary selling point was basically "it's easier to write a compiler for than Algol"
I don't hate C, but we can do a lot better with hindsight and at this point the amount of damage caused by foisting null terminated strings on the world is inexcusable.
As a "userspace" Rust developer, I'm happy that this still appears to be close enough to the standard Rust dialect that I could still be productive. I suspect that allocations are intentionally a little more explicit.
It would be cool if there was a few easy-for-beginner tasks to pick up and try my hand at this sort of work.
A big eventual non-technical goal of the Rust for Linux project is to reduce the barrier to entry for kernel programming, Rust is a good language for averting gumption traps IMO †
† https://en.wiktionary.org/wiki/gumption_trap
Why do I have a feeling that using Rust for such kind of low-level programming would actually make development less straightforward than when using C which was made specifically for that purpose? I mean, it's better to pick a right tool for a job, rather than try to push and shape a favourite tool which is better used in other scenarios.
Rust was also made specifically for the purpose of writing code like this.
Nobody is trying to “push and shape a favorite tool.” Take it from greg-kh:
https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pu...
> The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)
> Rust isn't a "silver bullet" that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn't we want that?
I had my journey of using Rust to implement a WinAPI-based app in which I did lots of unsafe (from Rust's point of view) operations. I spent more time on fighting with Rust's protections than on the actual implementation. The result code wasn't safe and looked horrible - totally opposite of what Rust code should look like. And yes, I followed "the Rust way" of doing things.
As much as I really like the mechanics of Rust and the language itself, I don't think I'm gonna use it for any of the device drivers I'm working on.
The problems you have quoted are due to developers being sloppy. I've gone through hundreds of source codes in Kernel, and most of them wouldn't pass code review in my company - cutting-corners everywhere, multipurpose functions, lack of documentation; those are issues which can't be fixed by just changing a language. Sure it will protect developers from missing "free()" here and there, but it's gonna bite from another side.
> I had my journey of using Rust to implement a WinAPI-based app in which I did lots of unsafe (from Rust's point of view) operations. I spent more time on fighting with Rust's protections than on the actual implementation. The result code wasn't safe and looked horrible - totally opposite of what Rust code should look like. And yes, I followed "the Rust way" of doing things.
I hate to just directly question your last statement, but “tons of unsafe” is a red flag that the way things are being done. You should need it for direct interactions with a C API, or for the lowest level of interacting with bare metal memory registers, or for lowest level high performance code that’s verging on or actually using assembly.
I can see how doing windows API stuff would cause a lot of the FFI usage of unsafe, but that should be handled by the winapi or a windows api crate that converts things to idiomatic rust and the rest of the codebase would be dealing with logic.
Entirely possible you hit an edge case here where you were writing glue code which exclusively talked to hand-optimized SSE algorithms or something, but that is exceedingly rare compared to someone just starting out who’s experienced with C trying to do things the C way and fighting through unsafe rather than looking for and finding higher-level patterns that are idiomatic.
> I've gone through hundreds of source codes in Kernel, and most of them wouldn't pass code review in my company - cutting-corners everywhere, multipurpose functions, lack of documentation; those are issues which can't be fixed by just changing a language.
Except they are mitigated to such a degree that it again makes me doubt you were coding idiomatically.
Rust tends to force you to exhaustively handle code paths, so it will require a lot of explicit opting out to cut corners.
Type-safety tends to help a lot in making multipurpose functions self-verifying. Function chains come up a lot more in Rust and type inference works so well because of this.
Documentation is a lot easier when you can just have people use “cargo doc” and add a bit of markdown and some doctests that will get exercised by CI.
> Sure it will protect developers from missing "free()" here and there, but it's gonna bite from another side.
RAII is the smallest difference in DX in Rust compared to working in C. For me the biggest differences were tooling, and type-safety making it a lot easier to catch bugs at compile-time, and enforce design assumptions I had about the architecture.
I don’t necessarily expect it to be easier to write Rust code, but I do expect it will catch more issues up-front rather than at runtime or in the field, so you will end up doing more code-compile iterations (seconds to minutes) and fewer code-customer iterations (hours to days or weeks).
Though when it comes to C++, there is less surface area of the language to learn to get to the modern “safe” constructs and the constructs enforce their own proper usage rather than expecting the developer to, so I expect an intermediate developer to be writing better code until a C++ developer gets to an expert level.
when you say "i did lots of unsafe operations", i think it contractions the claim that you "followed the rust way of doing things". what's the point of using a "memory-safe" language if you just gonna use unsafe blocks and ignore that? i agree with you point that there's some operations that rust sucks and c is a better option although. but my claim is that writing unsafe rust and safe are diferent things, for example they created a book talking just about unsafe rust -> https://doc.rust-lang.org/nomicon/
How much experience you have with: C, Rust and Kernel development?
Can't count in years because for my 9-5 work I use different languages. I started learning C when I was 15, now I'm over 30, and it constantly appears somewhere in my life, whether this is embedded or desktop development. Kernel - occasionally, when I must adapt or implement a device driver. Rust - I had three approaches, all of them related to WinAPI-based programs, but didn't suit my needs. I like it, I will come back to it at some point for sure, but definitely not in the context of Kernel.
You wanna hire me?
C really wasn't designed to handle common low-level hurdles any more than the CPUs that created the problems were. Just because you can formulate solutions doesn't mean shooting yourself in the foot isn't easier.
Applying the phrase "designed" to C is already dubious. It's a language that evolved from a very minimal and not terribly "designed" thing based off predecessor languages whose primary selling point was basically "it's easier to write a compiler for than Algol"
I don't hate C, but we can do a lot better with hindsight and at this point the amount of damage caused by foisting null terminated strings on the world is inexcusable.