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

41–50 of 240 posts

Re: Upcoming Rust language features for kernel development

#41

Post by IshKebab »

pjmlp wrote: post #10
timschmidt wrote: post #8

Earlier quoted context omitted.

> for everything else on userspace compiled managed languages are a much better option As someone who's written a number of userspace applications in many languages as well as embedded firmwares running on bare metal, Rust is a rare gem that excels at both.

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

Sure, but that's true of basically every language except maybe C++, C#, Javascript/Typescript and Dart.

GUIs are incredibly hard and most languages never get high quality GUI libraries. Rust is still pretty young and a ton of people are working on the problem so that will definitely change.

Re: Upcoming Rust language features for kernel development

#42

Post by onionisafruit »

ogoffart wrote: post #34
timschmidt wrote: post #30

Earlier quoted context omitted.

I looked at Slint a couple years ago when I was evaluating UI toolkits. Looks slick! The only thing that turned me off was needing an additional DSL to define UIs. Trying to learn fewer languages, more deeply, these days. Is it possible to use Slint without the DSL?

Slint does require using its DSL to define UIs, but I'd argue it's not really like learning a whole new language. It's not harder than learning the API surface of any other GUI framework. I actually wrote a blog post about this exact topic, since it's a common question: https://slint.dev/blog/domain-specific-language-vs-imperativ...

That’s a compelling post. You drew me in by calling SQL a DSL. You’re right, but if you asked me to list the DSLs I use regularly I never would have thought of SQL until now. My thinking was too uptight because I didn’t consider the “domain” in DSL could be something as big as querying structured data. That makes me wonder if Rust is a DSL for the domain of general computing (obviously not in the usual intended meaning of DSL).

Like the person you’re replying to, I am generally averse to DSLs where the domain is a single project because I associate them with previous bad experiences where I spent time learning only to find it totally misses the mark. There’s also the issue of software where I’m the sole maintainer and look at it rarely. If it’s the only place I use Slint, then I’m going to be worried that I need to relearn the DSL in three months when I want to tweak the UI. Although you can probably say the same about any non-trivial framework’s API whether or not it uses a DSL.

All that said, I’ll be a bit more open to DSLs after reading your post, and if I ever need to write a GUI in Rust I’ll give Slint a shot (although that seems unlikely since I don’t typically write Rust or GUIs).

Re: Upcoming Rust language features for kernel development

#43

Post by pjmlp »

adwn wrote: post #39
pjmlp wrote: post #7

Earlier quoted context omitted.

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.

> for everything else on userspace compiled managed languages are a much better option That might be true if you're developing a pure application [1], but not if you're writing a library. Have fun integrating a C# library in a Java program, a Java library in a C# program, or either of those in a Python, Node, C, C++, or Rust program. There's something to be said for not requiring a runtime. [1] Unless you care about…

OS IPC exists for a reason, aren't microservices all the rage nowadays, and Plan 9 rules?

Re: Upcoming Rust language features for kernel development

#44

Post by adwn »

pjmlp wrote: post #43
adwn wrote: post #39

Earlier quoted context omitted.

> for everything else on userspace compiled managed languages are a much better option That might be true if you're developing a pure application [1], but not if you're writing a library. Have fun integrating a C# library in a Java program, a Java library in a C# program, or either of those in a Python, Node, C, C++, or Rust program. There's something to be said for not requiring a runtime. [1] Unless you care about…

OS IPC exists for a reason, aren't microservices all the rage nowadays, and Plan 9 rules?

> OS IPC exists for a reason

Message-passing IPC is much, much slower and less efficient than shared-memory communication, and inter-process IPC (both message-passing and shared-memory) is much less convenient than intra-process multi-threading. Rust is the only mainstream language, managed or otherwise, which enables safe and efficient multi-threading.

Re: Upcoming Rust language features for kernel development

#45

Post by aliceryhl »

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.

Re: Upcoming Rust language features for kernel development

#46

Post by Foxboron »

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…

> C interop is excellent and has been for years.

Only if you primarily work with `cargo` and want to interact with C from Rust. The other way around has far less support and `rustc` does not standardize the object generation. This is actively preventing projects like `systemd` to adopt Rust into their project as an example.

https://github.com/systemd/systemd/pull/19598

Re: Upcoming Rust language features for kernel development

#47

Post by a-dub »

> 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't even really in use. from what i can tell even the android binder rust rewrite is vestigial.

the whole thing seems kinda cute but like, shouldn't this experiment in programming language co-development be taking place somewhere other than the source tree for the world's most important piece of software?

redox is a pretty cool experimental piece of software that might be the os of the future, why not do it there?

Re: Upcoming Rust language features for kernel development

#48

Post by pjmlp »

adwn wrote: post #44
pjmlp wrote: post #43

Earlier quoted context omitted.

OS IPC exists for a reason, aren't microservices all the rage nowadays, and Plan 9 rules?

> OS IPC exists for a reason Message-passing IPC is much, much slower and less efficient than shared-memory communication, and inter-process IPC (both message-passing and shared-memory) is much less convenient than intra-process multi-threading. Rust is the only mainstream language, managed or otherwise, which enables safe and efficient multi-threading.

Not at all, because as I explain on another sibiling answer, it is only safe if we cut down the use cases to a very specific one that helps to sell that narrative.

Re: Upcoming Rust language features for kernel development

#49

Post by dmm »

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…

The gpu driver for Apple silicon is Rust and the author stated it would have been much more difficult to implement in C. It isn't upstreamed yet.

""" Normally, when you write a brand new kernel driver as complicated as this one, trying to go from simple demo apps to a full desktop with multiple apps using the GPU concurrently ends up triggering all sorts of race conditions, memory leaks, use-after-free issues, and all kinds of badness.

But all that just… didn’t happen! I only had to fix a few logic bugs and one issue in the core of the memory management code, and then everything else just worked stably! Rust is truly magical! Its safety features mean that the design of the driver is guaranteed to be thread-safe and memory-safe as long as there are no issues in the few unsafe sections. It really guides you towards not just safe but good design. """

https://asahilinux.org/2022/11/tales-of-the-m1-gpu/

> the whole thing seems kinda cute but like, shouldn't this experiment in programming language co-development be taking place somewhere other than the source tree for the world's most important piece of software?

Torvalds seems to disagree with you.

Post reply on HN