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

181–190 of 240 posts

Re: Upcoming Rust language features for kernel development

#181

Post by 0x457 »

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, lifetime in structs are PITA. However, IMO using them is "the right choice" only in certain situations where performance hit from not using it is too much. I get why serde uses it, but notice who those don't get exposed to end user that much.

Re: Upcoming Rust language features for kernel development

#182

Post by jgilias »

aliceryhl wrote: post #45
kachapopopow wrote: post #16

Everytime features are mentioned it makes me go: "it's all fun and games until someone puts tokio into the kernel", better yet if rust becomes complete enough and someone makes a direct composition renderer we could have entire applications that run entirely in the kernel which could be... interesting.

It's trivial to implement an async runtime in the kernel. The kernel's workqueue is already essentially a runtime.

I was about to take offence at the use of “trivial” in this context. But then I noticed your handle, lol. You have the license to say that, thanks for your contributions!

Re: Upcoming Rust language features for kernel development

#183

Post by jojomodding »

sesm wrote: post #29
PoignardAzur wrote: post #4

> The final design, taking inspiration from C++, would be a form of guaranteed optimization, where constructing a new value and then immediately moving it to the heap causes it to be constructed on the heap in the first place. Note that there's some discussion about the name of that proposal, because "optimization" gives the wrong idea (that it's optional or could depend on the backend).

Why make this a behind-the-scene optimization instead of just introducing `new`? That would make things much more clear for everyone.

Because constructors are really weird. Usually in Rust, when a struct is constructed, it already upholds all its invariants because construction is the "last" step in the initialization function. But with a C++-like constructor, it starts with a struct where all fields are in an invalid state, and then the struct's invariants are slowly established field by field. This is kinda impossible to square with Rust's safety promise. Even in safe languages like Java, there are often bugs when one calls other function from the constructor, that now observes the instance under construction violating its usual invariants. And this is also something Rust wants to avoid.

Re: Upcoming Rust language features for kernel development

#184

Post by Maxatar »

jstimpfle wrote: post #174
meisel wrote: post #119

Earlier quoted context omitted.

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…

Why check this != other? I've seen this once before in a codebase and concluded it was unnecessary. Asking as someone whose life became much easier after opting not do anything of the above and just write C in C++ ;-)

Consider a move assign to a vector from src to this. The first step is for this to free its resources, the second step is to assign src resources to this, the third step is to set src resources to null.

If src and this are equal and you don't check for it, then you end up destroying src/this resources and the end result would be an empty vector (since the last step is to clear everything out).

The expected behavior is a no-op.

Re: Upcoming Rust language features for kernel development

#185

Post by dapperdrake »

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…

It seems like Rust is being thorough. This is the way.

Re: Upcoming Rust language features for kernel development

#186

Post by pama »

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…

I have been out of it for a while and dont miss it much, but I thought that the rule of zero, not five, was the modern goal.

Re: Upcoming Rust language features for kernel development

#187

Post by Maxatar »

PoignardAzur wrote: post #4

> The final design, taking inspiration from C++, would be a form of guaranteed optimization, where constructing a new value and then immediately moving it to the heap causes it to be constructed on the heap in the first place. Note that there's some discussion about the name of that proposal, because "optimization" gives the wrong idea (that it's optional or could depend on the backend).

C++ uses the term elision for these kinds of semantics.

Re: Upcoming Rust language features for kernel development

#188

Post by inhumantsar »

kstrauser wrote: post #162
ameliaquining wrote: post #145

Earlier quoted context omitted.

Note that the community has somewhat soured on that particular proposal and it's probably not going to be enacted in its current form, precisely because it's so complicated. ( https://rust-lang.github.io/rust-project-goals/2025h2/ergono... ) Complexity is not necessarily an automatic dealbreaker for a Rust language proposal—lots of Rust features are complicated because they solve problems that don't admit simple solu…

As a side note, this might just be a me thing, but I distinguish between "complex" and "complicated". Certain things have an inherently complexity. Stripped to their essence, they're still going to have a lot of moving parts. It's just their nature. However, you can also add complication on top of something that makes it more complex than it needs to be to perform its function. Think "complication" in the watchmaker'…

> Simple is better than complex. > > Complex is better than complicated.

https://peps.python.org/pep-0020/

Re: Upcoming Rust language features for kernel development

#189

Post by teaearlgraycold »

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.

Any time I need to explicitly give a lifetime in a struct I use an Rc or some other container. I’ve been using rust casually for years and every time I try to appease the compiler with lifetimes I realize it’s not worth my time. If someone has a very ELI5 resource that will make me understand when and why to do this I’d appreciate it.

IMO this is something that should just be handled by extra runtime code or a magically smarter compiler. Lifetime management feels like something that matters in a microcontroller or hyper-optimized setting, but never when I’m executing code on Apple Silicon for a random application. And yet the language makes simple GC ergonomically painful. I love the language but don’t really need all of that performance. I would gladly take a 1% hit to increment reference counts.

Re: Upcoming Rust language features for kernel development

#190

Post by jstimpfle »

Maxatar wrote: post #184
jstimpfle wrote: post #174

Earlier quoted context omitted.

Why check this != other? I've seen this once before in a codebase and concluded it was unnecessary. Asking as someone whose life became much easier after opting not do anything of the above and just write C in C++ ;-)

Consider a move assign to a vector from src to this . The first step is for this to free its resources, the second step is to assign src resources to this , the third step is to set src resources to null. If src and this are equal and you don't check for it, then you end up destroying src / this resources and the end result would be an empty vector (since the last step is to clear everything out). The expected behavi…

Right you said move but I was thinking of swap for some reason.

I probably still wouldn't care, unless it's clear that moving to self is even required. Trying to break everything in a thousand pieces and generalizing and perfecting them individually is a lot of busywork.

Post reply on HN