Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upcoming Rust language features for kernel development

lwn.net

Post reply on HN
Print view View original

151–160 of 240 posts

Re: Upcoming Rust language features for kernel development

#151

Post by mcherm »

remix2000 wrote: post #86
Dr_Emann wrote: post #81

Earlier quoted context omitted.

Thats kinda the problem, there are concepts in rust that don't have equivalents in other common languages. In this case, rust's type system models data-race-safety: it prevents data races at compile time in a way unlike what you can do in c or c++. It will prevent getting mutable access (with a compile time error) to a value across threads unless that access is syncronized (atomics, locks, etc)

And from what I can see, rustlang mutability is also a type system construct? I.e. it assumes that all other code is Rust for the purpose of those checks?

Yes. Just like C++ "const" is a type system construct that assumes all other code is C++ (or at least cooperates with the C++ code by not going around changing random bytes).

As far as I can tell, ANY guarantee provided by ANY language is "just a language construct" that fails if we assume there is other code executing which is ill-behaved.

Re: Upcoming Rust language features for kernel development

#152

Post by andrepd »

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…

A very interesting post about this issue.

https://smallcultfollowing.com/babysteps/blog/2025/10/07/the...

Re: Upcoming Rust language features for kernel development

#153

Post by steveklabnik »

tonyplee wrote: post #105

Are there any researches/works/agents into use LLM to auto covert some/all C code to Rust? Ask LLM to generate rust code from chat, usb, i2c, GPU drivers - build and test it automatically? Possible? Or start with other "smaller" projects such as sqlite, apache, nginx, etc - possible?

Darpa is interested in funding such an effort, but as far as I know that's the stage it's at, they haven't released any results.

Re: Upcoming Rust language features for kernel development

#154

Post by aw1621107 »

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...

> Stateful Metaprogeamming

Bit of a fun fact, but as one of the linked articles states the C++ committee doesn't seem to be a fan of stateful metaprogramming so its status is somewhat unclear. From Core Working Group issue 2118:

> Defining a friend function in a template, then referencing that function later provides a means of capturing and retrieving metaprogramming state. This technique is arcane and should be made ill-formed.

> Notes from the May, 2015 meeting:

> CWG agreed that such techniques should be ill-formed, although the mechanism for prohibiting them is as yet undetermined.

[0]: https://cplusplus.github.io/CWG/issues/2118.html

Re: Upcoming Rust language features for kernel development

#155

Post by loeg »

selfmodruntime wrote: post #110
a-dub wrote: post #88

Earlier quoted context omitted.

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.

> 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. No, they are not. You also don't need mutex ordering as much since Mutexes in Rust are a container type. You can only get ahold of the inside value as a reference when calling the lock method.

> You also don't need mutex ordering as much since Mutexes in Rust are a container type. You can only get ahold of the inside value as a reference when calling the lock method.

Mutex as a container has no bearing on lock ordering problems (deadlock).

Re: Upcoming Rust language features for kernel development

#156

Post by School-Cotton »

remix2000 wrote: post #140
gpm wrote: post #107

Earlier quoted context omitted.

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).

> 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

Well, yes, but that's the whole value of Rust: you don't need to use these overly-cautious defensive constructs, (at least not to prevent data races), because the language prevents them for you automatically.

Re: Upcoming Rust language features for kernel development

#157

Post by 0x457 »

afavour wrote: post #135
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.

> Case in point, my first read on lifetimes just left me confused. So I used Rc everywhere and made a perfectly functional program.

Curious, did you run into lifetime issues or just started wrapping everything in Rc after reading about lifetimes? Wrapping everything in Rc isn't even a bad thing, that's what you have to when you do WASM in a browser.

I still find it confusing sometimes because you're not setting lifetime, you're just giving it a name so that the compiler can reason about it.

Like saying something 'static doesn't make it static, it supposed to mean "live until program closes", but you can totally create things with 'static and free them before program exits.

Re: Upcoming Rust language features for kernel development

#158

Post by afavour »

0x457 wrote: post #157
afavour wrote: post #135

Earlier quoted context omitted.

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.

> Case in point, my first read on lifetimes just left me confused. So I used Rc everywhere and made a perfectly functional program. Curious, did you run into lifetime issues or just started wrapping everything in Rc after reading about lifetimes? Wrapping everything in Rc isn't even a bad thing, that's what you have to when you do WASM in a browser. I still find it confusing sometimes because you're not setting lifet…

It's been so long I can barely remember now but I'm pretty sure it was the lifetime propagation that got me... once one struct had it, every struct using that struct needed one, then there was more than one lifetime and combining them (and establishing the rules of how the lifetimes related to each other) bent my brain out of shape. Rc let me sidestep all of that.

Re: Upcoming Rust language features for kernel development

#159

Post by rcxdude »

afavour wrote: post #158
0x457 wrote: post #157

Earlier quoted context omitted.

> Case in point, my first read on lifetimes just left me confused. So I used Rc everywhere and made a perfectly functional program. Curious, did you run into lifetime issues or just started wrapping everything in Rc after reading about lifetimes? Wrapping everything in Rc isn't even a bad thing, that's what you have to when you do WASM in a browser. I still find it confusing sometimes because you're not setting lifet…

It's been so long I can barely remember now but I'm pretty sure it was the lifetime propagation that got me... once one struct had it, every struct using that struct needed one, then there was more than one lifetime and combining them (and establishing the rules of how the lifetimes related to each other) bent my brain out of shape. Rc let me sidestep all of that.

Yeah, once you're putting lifetimes in structs you're liable to run into trouble. In general you only want to do that for structs which are not expected to have long or complicated lifetimes (i.e. if you're expecting it might be allocated on the heap, it's likely too complicated to be workable)

Re: Upcoming Rust language features for kernel development

#160

Post by tredre3 »

vlovich123 wrote: post #134
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 askin…

> This is distinctly not a superpower c++ has and why the complexity

I guess you don't have that much experience with actual C++ development? Because there's a plethora of static analysis tools and any serious IDE come with refactoring tools on top of that, both assistive and automated, that will suggest fixes as you type. Rust didn't invent anything with clippy, however good the tool might be...

Post reply on HN