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

211–220 of 240 posts

Re: Upcoming Rust language features for kernel development

#211

Post by yencabulator »

ogoffart wrote: post #24
timschmidt wrote: post #11

Earlier quoted context omitted.

Well https://github.com/timschmidt/egui-rad-builder has come together rather well in the last week of hacking, if I say so myself. I think building a similar app with QT, for example, would have been significantly more challenging. I'm particularly fond of how easy it was to make all the controls live in the editor, and editable with changes appearing immediately. imgui would probably provide a similar experience, bu…

Regarding Rust GUI framework, there is also Slint https://slint.dev (Disclaimer: I'm one of the Slint developers.)

Slint is not a great option:

https://github.com/slint-ui/slint?tab=License-1-ov-file#read...

Re: Upcoming Rust language features for kernel development

#212

Post by zacmps »

pjmlp wrote: post #7
hannesfur wrote: post #2

These seem like the first features that Rust in Linux bring to the Rust language that are not almost exclusively useful to the kernel. In my perception the focus on bringing features for the kernel has held up development in other parts of the language and the standard library.

I see Rust's place on low level systems programming, for everything else on userspace compiled managed languages are a much better option, systems following an architecture like Self, Inferno or Android, so I don't see a big deal with these efforts focusing on low level C like capabilities.

This is not the view everyone holds. For an example of work in the opposite direction see https://dioxus.notion.site/Dioxus-Labs-High-level-Rust-5fe1f....

Re: Upcoming Rust language features for kernel development

#213

Post by gpm »

heavyset_go wrote: post #207
3836293648 wrote: post #54

Earlier quoted context omitted.

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.

The kernel doesn't use any C++, so no more than incidentally.

There is some C++/rust interop in the past that I've worked on that would have enjoyed the arbitrary self types feature, but not particularly because of the C++ part of the equation. In fact I think if it had been a pure rust project it would also have enjoyed that feature just as much so... eh... take it for what little it's worth I guess.

Re: Upcoming Rust language features for kernel development

#214

Post by School-Cotton »

izacus wrote: post #55
koverstreet wrote: post #51

Earlier quoted context omitted.

"Experiment" is a misnomer. Rust has been around long enough and demonstrated more than enough real advantages in writing reliable code that we know it's what we want to be doing.

But WHERE is that code in the kernel? That, I think, it the OPs point. Where is that demonstration?

The main real-world example of Rust kernel code is the Asahi GPU driver, which has not merged upstream yet, but it does use the upstream interfaces you're seeing.

Re: Upcoming Rust language features for kernel development

#215

Post by 3836293648 »

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.

Won't that be an eager runtime though? Breaking Rust's assumption that futures do nothing until polled? Unless you don't submit it to the queue until the poll call, I guess

Re: Upcoming Rust language features for kernel development

#217

Post by aw1621107 »

DaanDeMeyer wrote: post #180
aw1621107 wrote: post #85

Earlier quoted context omitted.

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

https://github.com/rust-lang/rust/issues/73632 needs to be addressed and then integrated into meson before systemd could consider adopting rust.

Thanks for the example!

I guess looking at that pedantically that's "just" a tooling issue, rather than an issue with the Rust language itself. That's not really a useful distinction from an end user's perspective, though; it's friction either way, and worth addressing.

Re: Upcoming Rust language features for kernel development

#218

Post by vlovich123 »

vlovich123 wrote: post #137
turtleyacht wrote: post #128

Earlier quoted context omitted.

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

Oh and to add on, in c++ there’s no borrow checker and no language guarantees that exploit UB in the way Rust does with ownership. What does it matter if two parts of a single threaded program have simultaneous mutable references to something - it’s not a safety or correctness issue as there’s no risk of triggering UB and there’s no ill formed program that could be generated that way. IMHO a RefCell equivalent in C++ is utterly pointless.

Re: Upcoming Rust language features for kernel development

#219

Post by vlovich123 »

kstrauser wrote: post #163
tredre3 wrote: post #160

Earlier quoted context omitted.

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

I worked for Coverity and people paid us ludicrous amounts of money to get the kinds of suggestions that rustc and clippy give everyone for free. I'm a huge fan.

Correct. Defaults matter. Also, even if you have a coverity license, you have to do the work of integrating it into your build system. cargo clippy works always and will cover all platforms and architectures you try to build for. This is significantly harder in c++ to the point where I’ve rarely seen coverity and other static analysis tools in use in large c++ code bases.

Re: Upcoming Rust language features for kernel development

#220

Post by kstrauser »

vlovich123 wrote: post #219
kstrauser wrote: post #163

Earlier quoted context omitted.

I worked for Coverity and people paid us ludicrous amounts of money to get the kinds of suggestions that rustc and clippy give everyone for free. I'm a huge fan.

Correct. Defaults matter. Also, even if you have a coverity license, you have to do the work of integrating it into your build system. cargo clippy works always and will cover all platforms and architectures you try to build for. This is significantly harder in c++ to the point where I’ve rarely seen coverity and other static analysis tools in use in large c++ code bases.

Not to mention that `cargo clippy` runs in 200ms, making it far and away the fastest such thing I've used with any language. It's a lot easier to make your code clean when the checker runs nearly instantaneously.
Post reply on HN