Upcoming Rust language features for kernel development • Hacker News Board

Re: Upcoming Rust language features for kernel development

#191

Post by zozbot234 » Thu, Oct 16, 2025, 8:32 PM UTC

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

AIUI, that's why MaybeUninit exists. But even if you address the issue of it being unsafe to assert that a MaybeUninit has been initialized (which &out references could in principle solve) there are real problems with this; for example, MaybeUninit has no niches or free-for-use padding even when T does, so you can't just "project" MaybeUninit to individual fields except in special cases. My understanding is that C++ partial initialization has the exact same issues in principle, they just don't come up as often because the standard for code correctness is a lot less rigorous.

Re: Upcoming Rust language features for kernel development

#192

Post by JoshTriplett » Thu, Oct 16, 2025, 8:34 PM UTC

In my opinion, it's not just about the complexity of C++ vs Rust. It's how often the complexity (or anything else) can unpleasantly surprise you, and how serious the consequences of that surprise are.

Re: Upcoming Rust language features for kernel development

#193

Post by pif » Thu, Oct 16, 2025, 8:41 PM UTC

> Yet people seem to like making useful things in it so it must have gotten something right.

I'm not commenting on Rust, seriously! But I couldn't help to notice that this sentence is a non sequitur. Something right has been developed in PHP and Visual Basic, even in Javascript and Go; still, those developers who freely choose to use those abominations, they do deserve to be pointed at and made fun of.

Re: Upcoming Rust language features for kernel development

#194

Post by emseetech » Thu, Oct 16, 2025, 8:54 PM UTC

Go is a great language.

Re: Upcoming Rust language features for kernel development

#195

Post by jmyeet » Thu, Oct 16, 2025, 9:07 PM UTC

I don't think Rust is very complex. What you're doing is very complex. It's just that doing it in C/C++ lulls you into a false sense of security.

C++ is incredibly complicated. I mean there's a 278 page book just on initialization [1].

I have seen all sorts of bad multithreaded code that compilers have let someone write. It would've been much harder in Rust but Rust would've forced you to be correct. As an example, I've seen a pool of locks for message delivery where the locks are locked on one thread and unlocked on another. This would get deadlocked every now and again so every half second or so a separate process would just release all the locks.

[1]: https://leanpub.com/cppinitbook

Re: Upcoming Rust language features for kernel development

#196

Post by nialv7 » Thu, Oct 16, 2025, 9:31 PM UTC

> Looking at the rust rfc for the lightweight clones feature

while the Use trait (a better name is proposed [1]) is useful, but I don't see how the .use syntax adds any value over .clone()? If the compiler is able to perform those optimizations, it can also lint and ask the user to remove the unnecessary .clone()/change x.clone() to &x. IMO this is better than the compiler doing black magic.

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

Re: Upcoming Rust language features for kernel development

#197

Post by scott_w » Thu, Oct 16, 2025, 9:47 PM UTC

As someone who’s dipped their toes in it, I’d say Rust is complicated in theory but not as complicated in practice. I said on a different topic that LLMs help a bit with suggestions and you can start with suboptimal code, improving it as you get more confident.

Obviously I’m not building anything production ready in it but it’s been useful for a few apps that I’d previously been using Python for.

Re: Upcoming Rust language features for kernel development

#198

Post by okanat » Thu, Oct 16, 2025, 9:53 PM UTC

That's why everybody who cares about OS safety should invest into capability-based operating systems. They take the concept of Send and Sync and implement at the runtime of the entire computer.

Re: Upcoming Rust language features for kernel development

#199

Post by zozbot234 » Thu, Oct 16, 2025, 9:54 PM UTC

You're on Apple Silicon, which is the preferred platform for Swift. That does exactly what you're asking for wrt. ARC, and is memory safe.

Re: Upcoming Rust language features for kernel development

#200

Post by dathinab » Thu, Oct 16, 2025, 10:01 PM UTC

there is currently a lot of ongoing discussions about "easier light weight clones" not just in the context of the RFC but in general.

And from all the discussions I have seen this RFC is one of the less promising ones as it mixes up the concept of "implicitly doing an operation before moving something into a closure scope" and "light weight clones" in a confusing ambiguous way.

So I don't expect it to be accepted/implemented this way, but I expect something similar to happen.

Like for "light weight clones" use is a pretty bad name and new syntax isn't needed, if we start shortening a `.clone()` to `.use` because it saves 4 letters then we are doing something wrong. Similar if argue for it for niche optimization reasons instead of improving generic optimizations to have the same outcome we are doing something wrong IMHO.

And for the the scoping/closure aspect (i.e. a rust equivalent of C++ closures `[]` parts (e.g. [&x](){...}) then it also seems a bad solution. First it's a operation which relates to the closure scope not the call inside of it, so attaching it to the call inside of it isn't a grate idea. Especially given that you might have multiple places you pass a clone of x in and this leading to a lot of ambiguity not highlighted with any examples in the RFC. Secondly for this concept it isn't limited to "cheap clones" sometimes you have the same pattern for not-so-cheap clones (through it mainly matters for cheap clones). And lastly if we really add ways to define captures, why not allow defining captures.

Now sure if you have a good solution for more compact way to handle "not-copy but still cheap" sharing (cloning of handles/smart pointers) of values there it maybe could make sense to also allow it to happen implicitly outside of closure capture scope instead of the invocation scope. But I would argue it's an extension of an not yet existing handle/smart pointer ergonomic improvement and should be done after that improvement.

(yes, I'm aware they use `use` because it's already a keyword, but making a non-zero cost copy of a handle/smart pointer isn't exactly "use it" but more like "share it" :/)