Upcoming Rust language features for kernel development • Hacker News Board

Re: Upcoming Rust language features for kernel development

#131

Post by School-Cotton » Thu, Oct 16, 2025, 3:53 PM UTC

a-dub wrote: post #88

tialaramex wrote: post #74

Earlier quoted context omitted.

> What does rust have to do with thread safety [...] ? Rust inherently models this idea. Read about Rust's "Send" and "Sync" marker traits. e.g. https://doc.rust-lang.org/std/marker/trait.Send.html > Is rust going to synchronize shared memory access for me? Much better than that. (safe) Rust is going to complain that you can't write the unsynchronized nonsense you were probably going to write, shortcutting the step w…

aren't they just annotations? proper use of mutexes and lock ordering aren't that hard, they just require a little bit of discipline and consistency. i can't remember the last time i faced a data race to be honest. i guess the real question is, how well does it all hold up when you have teamwork and everything isn't strictly adherent to one specific philosophy.

> proper use of mutexes and lock ordering aren't that hard, they just require a little bit of discipline and consistency.

Wow, you must be really smart! I guess you don’t need rust. For the rest of us who find concurrent programming difficult, it is useful.

Re: Upcoming Rust language features for kernel development

#132

Post by School-Cotton » Thu, Oct 16, 2025, 3:55 PM UTC

remix2000 wrote: post #64

tobz1000 wrote: post #61

Earlier quoted context omitted.

The comment probably refers to data races over memory access, which are prevented by usage of `Send` and `Sync` traits, rather than more general race conditions.

I see, but that's not the point of my comment. I don't know rustlang, perhaps I could address that if someone translated the rust-specific parlance to more generally accepted terms.

There’s no programming language called “rustlang”. It’s just rust.

Re: Upcoming Rust language features for kernel development

#133

Post by humanrebar » Thu, Oct 16, 2025, 3:55 PM UTC

aw1621107 wrote: post #85

Foxboron wrote: post #46

Earlier quoted context omitted.

> C interop is excellent and has been for years. Only if you primarily work with `cargo` and want to interact with C from Rust. The other way around has far less support and `rustc` does not standardize the object generation. This is actively preventing projects like `systemd` to adopt Rust into their project as an example. https://github.com/systemd/systemd/pull/19598

> Only if you primarily work with `cargo` and want to interact with C from Rust. In what way(s) does Rust's C interop depend on cargo? > The other way around has far less support and `rustc` does not standardize the object generation. I believe in this context the understanding is that you're going to be using `extern "C"` and/or `#[repr(C)]` in your Rust code, which gives you a plain C interface. I think attempting…

> In what way(s) does Rust's C interop depend on cargo?

Do rust and cargo allow for multiple interpretations of the same C header file across different objects in the same program? That's how C libraries are often implemented in practice due to preprocessor tricks, though I wish it wasn't normal to do this sort of thing.

Re: Upcoming Rust language features for kernel development

#134

Post by vlovich123 » Thu, Oct 16, 2025, 4:01 PM UTC

bobajeff wrote: post #100

Looking at the rust rfc for the lightweight clones feature [1]. It took me a while to sort of understand it. Once I did I was excited for the feature but after awhile I was once again struck by the observation that rust is a very complex language to learn. To me as someone who's not learned either it looks like all the concepts and features of 'true' modern C++ (as opposed to C + a few extra features) spliced with th…

Aside from the complexity not being possible to misuse (which is trivial in C++), I still find it easier. Moreover, even if you didn’t know about this if you use clippy it’ll suggest construct replacements that are more idiomatic. So even if you didn’t know about lightweight clones, you’ll get suggestions to leverage them once they’re available for your codebase (and you can apply the vast majority trivially by asking clippy to do it automatically via --fix). This is distinctly not a superpower c++ has and why the complexity of c++ keeps piling up with either no one using the new features or using them in unnecessarily complicated ways.

Re: Upcoming Rust language features for kernel development

#135

Post by afavour » Thu, Oct 16, 2025, 4:01 PM UTC

bobajeff wrote: post #100

Looking at the rust rfc for the lightweight clones feature [1]. It took me a while to sort of understand it. Once I did I was excited for the feature but after awhile I was once again struck by the observation that rust is a very complex language to learn. To me as someone who's not learned either it looks like all the concepts and features of 'true' modern C++ (as opposed to C + a few extra features) spliced with th…

I find that Rust is a language that feels insurmountable when you examine it from a distance but once you get your hands dirty it feels natural very quickly.

Case in point, my first read on lifetimes just left me confused. So I used Rc everywhere and made a perfectly functional program. Picking up lifetimes after mastering the basics made it a lot easier. Most people won't even need to care about lightweight clones.

Re: Upcoming Rust language features for kernel development

#136

Post by gpm » Thu, Oct 16, 2025, 4:07 PM UTC

uecker wrote: post #127

arnsholt wrote: post #89

Earlier quoted context omitted.

In discussions like this, I sometimes feel that the importance of related work like the increasing use of Rust in Android and MS land is under-appreciated. Those who think C is fine often (it seems to me) make arguments along the lines that C just needs to have a less UB-prone variant along the lines of John Regehr and colleagues' "Friendly C" proposal,[0] which unfortunately Regehr about a year and a half later conc…

Some parts of the industry with a lot of money and influence decided this is the way forward. IMHO Rust has the same issue as C++: it is too complex and a memory safe C would be far more useful. It is sad that not more resources are invested into this.

I'm entirely unconvinced that a low-level† memory safe C that is meaningfully simpler than rust is even possible, let alone desirable. IMHO Basically all of rust's complexity comes from implementing the structure necessary to make it memory safe without making it too difficult to use††.

Even if it is though, we don't have it. It seems like linux should go with the solution we have in hand and can see works, not a solution that hasn't been developed or proved possible and practical.

Nor is memory safety the only thing rust brings to the table, it's also brings a more expressive type system that prevents other mistakes (just not as categorically) and lets you program faster. Supposing we got this memory safe C that somehow avoided this complexity... I don't think I'd even want to use it over the more expressive memory safe language that also brings other benefits.

† A memory-safe managed C is possible of course (see https://fil-c.org/), but it seems unsuitable for a kernel.

†† There are some other alternatives to the choices rust made, but not meaningfully less complex. Separately you could ditch the complexity of async I guess, but you can also just use rust as if async didn't exist, it's a purely value added feature. There's likely one or two other similar examples though they don't immediately come to mind.

Re: Upcoming Rust language features for kernel development

#137

Post by vlovich123 » Thu, Oct 16, 2025, 4:10 PM UTC

turtleyacht wrote: post #128

AlotOfReading wrote: post #102

Earlier quoted context omitted.

Proper use of lock ordering is reasonably difficult in a large, deeply connected codebase like a kernel. Rust has real improvements here, like this example from the fuschia team of enforcing lock ordering at compile time [0]. This is technically possible in C++ as well (see Alon Wolf's metaprogramming), but it's truly dark magic to do so. [0] https://lwn.net/Articles/995814/

Borrow Checker, Lifetimes, and Destructor Arguments in C++ (2024) https://a10nw01f.github.io/post/advanced_compile_time_valida...

The lifetimes it implements is the now unused lexical lifetimes of early Rust. Modern rust uses non-lexical lifetimes which accepts a larger amount of valid programs and the work on Polonius will further allow more legal programs that lexical lifetimes and non lexical lifetimes can’t allow. Additionally, the “borrow checker” they implement is RefCell which isn’t the Rust borrow checker at all but an escape hatch to do limited single-threaded borrow checking at runtime (which the library won’t notice if you use in multiple threads but Rust won’t let you).

Given how the committee works and the direction they insist on taking, C++ will never ever become a safe language.

Re: Upcoming Rust language features for kernel development

#138

Post by mekoka » Thu, Oct 16, 2025, 4:12 PM UTC

lesuorac wrote: post #104

mynameisash wrote: post #97

Earlier quoted context omitted.

Also the guy that created "the world's most important piece of software", as you put it. Appealing to the authority on the exact thing you raised concern about is the single most important authority one can cite.

Eh? Surely it's better to cite the authority's reasons as to why they think this way than just to cite the authority itself ... It's not like there's a lack of times he's talked about rust. Just link his commentary similar to linking ashai linux.

> Surely it's better to cite the authority's reasons as to why they think this way than just to cite the authority itself

Why? When disagreeing with an authority, you want the audience to pay closer attention to your arguments as you demonstrate why the authority has it wrong. When you're just sharing distant and likely under-informed opinions with no arguments to back them up, it's not up to other people to do homework to show you why you're wrong. Appeal to authority is a legit call to a fallacy only when people give next to no consideration to your arguments, focusing instead on the opposing party's stature.

Re: Upcoming Rust language features for kernel development

#139

Post by GrantMoyer » Thu, Oct 16, 2025, 4:13 PM UTC

meisel wrote: post #119

bobajeff wrote: post #100

Looking at the rust rfc for the lightweight clones feature [1]. It took me a while to sort of understand it. Once I did I was excited for the feature but after awhile I was once again struck by the observation that rust is a very complex language to learn. To me as someone who's not learned either it looks like all the concepts and features of 'true' modern C++ (as opposed to C + a few extra features) spliced with th…

In my experience, C++ is a much more complicated language. The 8 ways to initialize something, the 5 types of values (xvalues etc.), inconsistent formatting conventions, inconsistent naming conventions, the rule of 5, exceptions, always remembering to check `this != other` when doing a move assignment operator, perfect forwarding, SFINAE, workarounds for not having a great equivalent to traits, etc. . Part of knowing…

Thanks for organizing for me my thoughts on why even a restricted modern subset of C++ is complicated.

Re: Upcoming Rust language features for kernel development

#140

Post by remix2000 » Thu, Oct 16, 2025, 4:18 PM UTC

gpm wrote: post #107

remix2000 wrote: post #64

Earlier quoted context omitted.

I see, but that's not the point of my comment. I don't know rustlang, perhaps I could address that if someone translated the rust-specific parlance to more generally accepted terms.

I'm not sure I understand the point of your comment at all. Rust does, successfully, guarantee the lack of data races. It also guarantees the lack of memory-unsafety resulting from race conditions in general (which to be fair largely just means "it guarantees a lack of data races", though it does also include things like "race conditions won't result in a use after free or an out of bounds memory access"). If by addr…

The point of my comment is that in my experience, incompetently written, overly-cautious code tends to be more safe at the expense of maintainability and/or performance.

Sadly, I don't know rustlang, so I can't tell if the inability to describe its features in more commonly used terms is due to incompetence or the features being irrelevant to this discussion (see the title of the thread).