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

201–210 of 240 posts

Re: Upcoming Rust language features for kernel development

#201

Post by dathinab »

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 mean yes, C++ managed to hit a uncanny overlap of being very overenginered in some aspects which to make it worse haven't focused at all on non-senior/export dev UX while also being underenginered in others aspects :/

They are trying to fix it in recent ~10 years, but they are also adding new clever expert features at the same time, so I kinda see it as a lost cause.

Rust isn't doesn't have "that" much less complexity if you take all the stable (or worse unstable experimental) things it has.

What makes Rust so nice is nearly always(1) if you don't use a feature you don't have to know about it (not so in C++) and if you stumble about a feature you don't know it's not just normally syntax visible but if you use it wrongly it won't segfault or even have a RCE due to out of bounds writes or similar.

So for C++ you have to learn a lot of the stuff upfront, but are not forced to by the compiler, and getting it wrong can have catastrophic consequences.

But for Rust you can learn it (mostly) bit by bit.

It's not perfect, when you go unsafe you are touching on a lot of "modern compiler" complexity which now also need to map to rust guarantees (but also have better save guards/visibility in Rust).

And async doesn't work so well with the bit by bit learning.

But in my personal experience if you don't have a team only consisting of senior C++ devs I would stay far away from C++. On the other hands with the right guidelines/limitations using rust with junior engineers is just fine (the guidelines matter to not get hangup on the wrong things or over-complicate things).

Re: Upcoming Rust language features for kernel development

#202

Post by IshKebab »

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…

The problem with C++'s complexity is that you have to remember all of it yourself and if you forget some of it... boom undefined behaviour and elusive runtime bugs!

Rust is definitely on the same order of magnitude of complexity, but you don't have to remember it all. Usually if you forget some complex rule and make a mistake, the compiler will tell you.

That's not true for unsafe Rust, but you rarely need unsafe Rust. Apart from FFI I have yet to use it at all and I've been writing Rust for years.

Async Rust is probably the closest it gets to C++'s "you didn't explicitly co_return in the context of a promise with no return_void? ok carry on but I'm going to crash sometimes! maybe just in release mode, on another OS".

Re: Upcoming Rust language features for kernel development

#203

Post by dev_l1x_be »

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.

Pretty good observation. I think the getting to know Rust documentation should just start with this. Use forget about lifetimes and just use Rc when needed.

Re: Upcoming Rust language features for kernel development

#204

Post by dev_l1x_be »

teaearlgraycold wrote: post #189
afavour wrote: post #158

Earlier quoted context omitted.

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 magica…

We have production systems, with ~10k Rust without lifetimes. Sometimes you can get away not using it.

Re: Upcoming Rust language features for kernel development

#205

Post by dathinab »

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…

I think lifetimes are best thought of as constraints.

Like `x: Foo` means "x is constrained by lifetime 'a" as in "x is only guaranteed to be soundly usable if 'a is 'alive'".

With the implicit context of "you are only allowed to use things which are guaranteed to be soundly usable".

And that "moving" is distinct from lifetimes (i.e. if you move x out of scope you just don't have it anymore, while a 'a constraint on x limits where you _can_ "have" it).

Then `'static` basically means "no constraint"/"unconstrained".

So a `x: X + 'static` mean x has no constraints, as long as you have it you can use it.

Where `x: X+'a` (or `X`) would mean you can _at most_ have x until 'a stops being "alive". (This doesn't mean the data behind X doesn't life longer, just that in that specific place you can't "have" it at most while 'a is alive).

So then if we look at `&'static A` we have a type which 1) is always copied instead of moved, so you always have it while you can have it and 2) you can always have it. As consequence it must life for the whole program execution. Not because `'static` says "until end of program" but because a unconstrained &reference can only be sound if it exist until the end of the program!!

Re: Upcoming Rust language features for kernel development

#206

Post by seabrookmx »

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.

I'm not sure if you're joking, but if not this is a fundamental misunderstanding of how Rust (and C) are used in the kernel.

Much like how you don't have the C stdlib when writing kernel code, Rust is used with the no_std option. You do not use cargo and do not have access to crates.

You'd likely have to rewrite half of tokio to use kernel level abstractions for things like sockets and everything else that interacts with the OS.

Re: Upcoming Rust language features for kernel development

#207

Post by heavyset_go »

3836293648 wrote: post #54
heavyset_go wrote: post #14

Earlier quoted context omitted.

What's the story with C interop now with these and related changes? I'm out of the loop.

It's C++ that is problematic, C has been easy for years

Are the kernel-related changes applicable to C++ interop? Honest question, I don't know.

Re: Upcoming Rust language features for kernel development

#208

Post by heavyset_go »

cyphar wrote: post #111
heavyset_go wrote: post #14

Earlier quoted context omitted.

What's the story with C interop now with these and related changes? I'm out of the loop.

Calling C code from Rust? Pretty nice. Writing Rust code to be called from C (but within the same application)? Doable but somewhat painful. Writing Rust code to act like a C shared library? Quite painful and some pretty important features are missing (proper symbol versioning support being the most obvious one). Theoretically doable if you're willing to compromise. There's also some aspects of FFI-safety that are ve…

Thanks for the info, I've been wanting to use Rust in a project with a lot of FFI going both Rust C ways. Still sounds like it's a bit hairy.

Re: Upcoming Rust language features for kernel development

#209

Post by heavyset_go »

muvlon wrote: post #31
heavyset_go wrote: post #14

Earlier quoted context omitted.

What's the story with C interop now with these and related changes? I'm out of the loop.

C interop is excellent and has been for years. The one piece that still needs unstable is defining/exposing varargs functions (support for calling them was stabilized many years ago). You can write almost anything you can write in C in (partly unsafe) Rust, in fact there are projects like c2rust that automate this translation. These new features are all about making things that the kernel devs need possible in safe R…

Cool, thanks for the clarification

Re: Upcoming Rust language features for kernel development

#210

Post by yencabulator »

a-dub wrote: post #47

> The Rust for Linux project has been good for Rust i just decided do a good ol' 'find -name "*.rs"' in the kernel tree to get a sense for what all this is about. from what i can tell, there's just an api compatibility layer (found in /rust) and then a smattering of proof of concept drivers in tree that appear to just be simple rewrites of existing drivers (with the exception of the incomplete nvidia thing) that aren…

> there's just an api compatibility layer (found in /rust)

Even figuring out what exactly the Linux kernel API safety rules are is a huge task, much less encoding them in a computer-readable form.

The code there is not about CRust FFI. It's about encoding Linux kernel API properties into a safe Rust API.

The uncertainty of the calling/ordering rules is exactly why kernel C has been hard to write. For VFS locking rules, you pretty much have to simulate Al Viro's brain and replay his whole life experience...

Post reply on HN