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.
Yeah, Rust tends to have enough type-safety that you can encode project-specific constraints to it and lower the learning curve to that of Rust itself, rather than learning all the idiosyncratic unconscious and undocumented design constraints that you need to abide by to keep from destabilizing things.
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 †
Maybe it's my frequently-flagged ass, but this comment doesn't seem to contribute less than most other language-oriented commentary. In fact, it seems more honest and wastes less of our time than most. There must be thousands of vapid opinions shared about programming languages on this site each week, most of which are actively distracting to fruitful conversation, and many of which engage in openly-counterproductive bike shedding over syntax, arguing over phrases like "low-level" vs "high-level", whether or not rust's borrow-checker is the key to nirvana or a major distraction holding back our best hackers, etc. It truly makes any discussion about programming languages difficult to stomach.
The above comment at least seems concise, pushes a narrative that actually makes sense (you should pick the right tool for the job, even if I personally think rust is better as I noted in a sibling comment 7 hours before you). The person is openly stating a feeling as a feeling rather than as some kind of nuanced position, which is better than most HN commenters can manage to admit. It certainly doesn't come off as flame bait or a generic tangent, certainly not even compared to most of the commentary in this or related threads.
Also, I don't know how to vouch for said comment. I really don't like the flagging system, and I really wish we could opt-out of respecting it from the view of our logged-in profile. Even the whole 'show dead' thing still preserves the semantics of flagging restricting interaction.
> "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
If this standard were consistently enforced, this site would be a graveyard. At some point we must grapple with how this obviously not-enforced rule is leveraged in seemingly-arbitrary places.
---
In short: I have no clue why this particular comment is singled out when most engagement on programming language is a distinctly more flagrant violation of the rules. Even if I happen to disagree with it.
I think the thing that made me respond to that comment, where I might not have to other similar ones, is that it was so plainly a generic tangent, moving the discussion in a repetitive/indignant direction—exactly opposite to the direction we hope threads will go. Also, such comments are particularly when the thread is new, and particularly bad at the toplevel.
> If this standard were consistently enforced, this site would be a graveyard
That sort of thing is super easy to say and feels good to say, but is plainly untrue. Alas, it has a destructive effect in its own right. If you guys knew how fragile everything is that we're trying (and failing) to achieve here, I think you would be more careful. It's a tragedy of the commons thing: it's feels better to point fingers and blame others for a deplorable shared situation, than to take responsibility for one's own contribution.
This is not to dispute that there are indeed a great many low-quality comments being posted to Hacker News. It bothers me and I wish it were otherwise.
> 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.
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/
We have literal decades of experience showing that the problem isn't "get good"--no matter how many best practices are followed, it turns out that the next generation of fuzzers or analyzers or whatnot is able to uncover yet more problems in the most perfect codebases we're aware of.
In my experience--and most others' too--it is far better to design APIs so that they are impossible to misuse, rather than relying on developers to remember the rules to prevent misuse. This is where maxims like "parse, don't validate" come from. C's type system is simply too weak for API misuse to be made compile-time failures, which means you have to rely on convention, and anyone who thinks that convention can be made robust across a multimillion line codebase is delusional. One of the advantages of Rust is that you can create newtypes which rewrap the APIs to make misuse impossible. I've been working on some numerics code in Rust, and the first thing I did was to make different types for the different kinds of indices (rows, columns, permuted rows, etc.) so that it's simply impossible to use the wrong index for a given array.
Also, one of those things I've noticed is that most of the people who are dismissive of Rust is that they point to its protection against 'missing "free()" here and there.' Which is strange, because it probably doesn't even make the top 10 list of problems in C that Rust protects against. The C issue that keeps me up at night when I write C code is pointer invalidation, which is what Rust's lifetimes + mutability xor aliasibility rules are meant to protect against. So why talk about free and not pointer invalidation?
> 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.
I agree with you there. Rust lets me spend my remaining brain cycles considering the logic and flow of my code, not worrying that I screwed up memory handling and such.
There is not one group of developers C folks won’t throw under the bus (eg by calling them sloppy) to defend C.
Like here you have one of the lead devs of the Linux kernel saying that Rust solves many problems that he has seen happen repeatedly in the kernel, and you’re saying “hm well they must just have been sloppy”.
Frankly there is a whole subsection of our profession which is composed of engineers who have differentiated themselves on their elite skills with difficult low-level languages, and if you pry that cultural marker away from them, they get defensive.
I see this in C/C++ forums all the time: "Rust doesn't solve a problem I have". Actually, yes it does. They might not think it, but I've been in enough codebases over the years by some very skilled C & C++ programmers to know better. The mistakes are preventable by a decent modern language that doesn't let you just null and leak all over the place in entirely preventable ways.
Rust has all sorts of problems, it's definitely not perfect. It is not the final form for systems programming languages.
But it's getting tiresome to see people who won't admit that the C legacy is a real problem at this point. And it's not like it (lack of safety, rigour, etc.) wasn't known along the way (or Ada would never have been a thing, etc.) -- it just wasn't considered important.
Well it should be now. Hell, in the kernel in privileged execution space more than anywhere else it is most important.
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.
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.
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.
Yeah, Rust tends to have enough type-safety that you can encode project-specific constraints to it and lower the learning curve to that of Rust itself, rather than learning all the idiosyncratic unconscious and undocumented design constraints that you need to abide by to keep from destabilizing things.
Nicely put
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
[flagged]
"Eschew flamebait. Avoid generic tangents."
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
https://news.ycombinator.com/newsguidelines.html
Maybe it's my frequently-flagged ass, but this comment doesn't seem to contribute less than most other language-oriented commentary. In fact, it seems more honest and wastes less of our time than most. There must be thousands of vapid opinions shared about programming languages on this site each week, most of which are actively distracting to fruitful conversation, and many of which engage in openly-counterproductive bike shedding over syntax, arguing over phrases like "low-level" vs "high-level", whether or not rust's borrow-checker is the key to nirvana or a major distraction holding back our best hackers, etc. It truly makes any discussion about programming languages difficult to stomach.
The above comment at least seems concise, pushes a narrative that actually makes sense (you should pick the right tool for the job, even if I personally think rust is better as I noted in a sibling comment 7 hours before you). The person is openly stating a feeling as a feeling rather than as some kind of nuanced position, which is better than most HN commenters can manage to admit. It certainly doesn't come off as flame bait or a generic tangent, certainly not even compared to most of the commentary in this or related threads.
Also, I don't know how to vouch for said comment. I really don't like the flagging system, and I really wish we could opt-out of respecting it from the view of our logged-in profile. Even the whole 'show dead' thing still preserves the semantics of flagging restricting interaction.
> "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
If this standard were consistently enforced, this site would be a graveyard. At some point we must grapple with how this obviously not-enforced rule is leveraged in seemingly-arbitrary places.
---
In short: I have no clue why this particular comment is singled out when most engagement on programming language is a distinctly more flagrant violation of the rules. Even if I happen to disagree with it.
I think the thing that made me respond to that comment, where I might not have to other similar ones, is that it was so plainly a generic tangent, moving the discussion in a repetitive/indignant direction—exactly opposite to the direction we hope threads will go. Also, such comments are particularly when the thread is new, and particularly bad at the toplevel.
> If this standard were consistently enforced, this site would be a graveyard
That sort of thing is super easy to say and feels good to say, but is plainly untrue. Alas, it has a destructive effect in its own right. If you guys knew how fragile everything is that we're trying (and failing) to achieve here, I think you would be more careful. It's a tragedy of the commons thing: it's feels better to point fingers and blame others for a deplorable shared situation, than to take responsibility for one's own contribution.
This is not to dispute that there are indeed a great many low-quality comments being posted to Hacker News. It bothers me and I wish it were otherwise.
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.
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/
We have literal decades of experience showing that the problem isn't "get good"--no matter how many best practices are followed, it turns out that the next generation of fuzzers or analyzers or whatnot is able to uncover yet more problems in the most perfect codebases we're aware of.
In my experience--and most others' too--it is far better to design APIs so that they are impossible to misuse, rather than relying on developers to remember the rules to prevent misuse. This is where maxims like "parse, don't validate" come from. C's type system is simply too weak for API misuse to be made compile-time failures, which means you have to rely on convention, and anyone who thinks that convention can be made robust across a multimillion line codebase is delusional. One of the advantages of Rust is that you can create newtypes which rewrap the APIs to make misuse impossible. I've been working on some numerics code in Rust, and the first thing I did was to make different types for the different kinds of indices (rows, columns, permuted rows, etc.) so that it's simply impossible to use the wrong index for a given array.
Also, one of those things I've noticed is that most of the people who are dismissive of Rust is that they point to its protection against 'missing "free()" here and there.' Which is strange, because it probably doesn't even make the top 10 list of problems in C that Rust protects against. The C issue that keeps me up at night when I write C code is pointer invalidation, which is what Rust's lifetimes + mutability xor aliasibility rules are meant to protect against. So why talk about free and not pointer invalidation?
> 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.
I agree with you there. Rust lets me spend my remaining brain cycles considering the logic and flow of my code, not worrying that I screwed up memory handling and such.
There is not one group of developers C folks won’t throw under the bus (eg by calling them sloppy) to defend C.
Like here you have one of the lead devs of the Linux kernel saying that Rust solves many problems that he has seen happen repeatedly in the kernel, and you’re saying “hm well they must just have been sloppy”.
Yep.
Frankly there is a whole subsection of our profession which is composed of engineers who have differentiated themselves on their elite skills with difficult low-level languages, and if you pry that cultural marker away from them, they get defensive.
I see this in C/C++ forums all the time: "Rust doesn't solve a problem I have". Actually, yes it does. They might not think it, but I've been in enough codebases over the years by some very skilled C & C++ programmers to know better. The mistakes are preventable by a decent modern language that doesn't let you just null and leak all over the place in entirely preventable ways.
Rust has all sorts of problems, it's definitely not perfect. It is not the final form for systems programming languages.
But it's getting tiresome to see people who won't admit that the C legacy is a real problem at this point. And it's not like it (lack of safety, rigour, etc.) wasn't known along the way (or Ada would never have been a thing, etc.) -- it just wasn't considered important.
Well it should be now. Hell, in the kernel in privileged execution space more than anywhere else it is most important.
> And yes, I followed "the Rust way" of doing things.
Alright show up buddy, let us code review
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.
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?
[flagged]
Please don't do this here. We detached this comment from https://news.ycombinator.com/item?id=44613757 and marked it off topic.