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

221–230 of 240 posts

Re: Upcoming Rust language features for kernel development

#221

Post by pjmlp »

mamcx wrote: post #112
pjmlp wrote: post #10

Earlier quoted context omitted.

Only if those userspace applications are headless, Rust exceling at GUIs is a bit of a strech.

> Rust exceling at GUIs is a bit of a strech. BTW, this happens to almost all languages. Which ACTUAL good GUIs toolkits exist ? And which ACTUAL languages HAVE good integration or implementation of them? A good GUI kit AND integration is a bigger task than do a Os or a RDBMS. (And neither are many good languages for RDBMS)

Delphi, VB, Java, Kotlin, Dart, C#, VB.NET, Swift, Objective-C.

All of the above also have great ORM libraries and RDBMS standard driver APIs, as doing data entry applications is a common enterprise GUI workflow.

Re: Upcoming Rust language features for kernel development

#222

Post by pjmlp »

dathinab wrote: post #201
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…

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

I keep reaching out to C++, because there is plenty of stuff out there that has C++ SDKs, or has their language runtimes partially written in C++, and adding another language in the middle like Rust will hardly help, only make the whole stack even more complex.

Re: Upcoming Rust language features for kernel development

#223

Post by kachapopopow »

seabrookmx wrote: post #206
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…

that's the joke. I've made most of c runtime work in the windows kernel before though.

Re: Upcoming Rust language features for kernel development

#224

Post by samus »

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

With Rc you're telling the compiler "I don't know the lifetime, or can't describe it to you using the Rust type system. Please figure it out at runtime."

Re: Upcoming Rust language features for kernel development

#227

Post by aliceryhl »

3836293648 wrote: post #215
aliceryhl wrote: post #45

Earlier quoted context omitted.

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

It won't be different from Tokio. When you pass a future to tokio::spawn, that will also eagerly execute the future right away.

Re: Upcoming Rust language features for kernel development

#228

Post by aliceryhl »

jgilias wrote: post #182
aliceryhl wrote: post #45

Earlier quoted context omitted.

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!

It never made it into upstream Linux, but there is already a sample implementation that Wedson wrote in 2022: https://github.com/Rust-for-Linux/linux/pull/798

Re: Upcoming Rust language features for kernel development

#229

Post by vlovich123 »

kstrauser wrote: post #220
vlovich123 wrote: post #219

Earlier quoted context omitted.

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.

And when you can pass —fix and the vast majority of suggestions are auto-applied

Re: Upcoming Rust language features for kernel development

#230

Post by mamcx »

pjmlp wrote: post #221
mamcx wrote: post #112

Earlier quoted context omitted.

> Rust exceling at GUIs is a bit of a strech. BTW, this happens to almost all languages. Which ACTUAL good GUIs toolkits exist ? And which ACTUAL languages HAVE good integration or implementation of them? A good GUI kit AND integration is a bigger task than do a Os or a RDBMS. (And neither are many good languages for RDBMS)

Delphi, VB, Java, Kotlin, Dart, C#, VB.NET, Swift, Objective-C. All of the above also have great ORM libraries and RDBMS standard driver APIs, as doing data entry applications is a common enterprise GUI workflow.

Well if that is what you call good from ORM (I agree Delphi for GUI, the others not so much).

A truly good one? FoxPro. Is very hard to know if you don't have exposure to what should be.

Post reply on HN