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

31–40 of 240 posts

Re: Upcoming Rust language features for kernel development

#31

Post by muvlon »

heavyset_go wrote: post #14
oersted wrote: post #5

Earlier quoted context omitted.

As I understand it systems programming is the priority application area for Rust, and there are plenty of projects working on OSs, embedded or other bare-metal cases, as well as interoperability with complex C codebases. At first glance, these features look quite general to me and not particularly tied to the kernel, they are important utilities for doing this kind of programming in the real world.

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 Rust. This often requires support for some quite fancy abstractions, some of which cannot be expressed in current stable Rust.

Re: Upcoming Rust language features for kernel development

#32

Post by cosmic_cheese »

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.

Indeed. Last I knew all the Rust UI libraries were declarative and/or immediate mode, both of which have their place but I’m not convinced that they’re suitable in all situations. Sometimes you need a boring “old style” imperative UI framework with deep toolbox of capable widgets (think AppKit, win32, etc), but that’s notably absent in the Rust world.

Re: Upcoming Rust language features for kernel development

#33

Post by timschmidt »

cosmic_cheese wrote: post #32
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.

Indeed. Last I knew all the Rust UI libraries were declarative and/or immediate mode, both of which have their place but I’m not convinced that they’re suitable in all situations. Sometimes you need a boring “old style” imperative UI framework with deep toolbox of capable widgets (think AppKit, win32, etc), but that’s notably absent in the Rust world.

https://www.gpui.rs/ is a relatively new entrant which is described as "hybrid immediate and retained mode". Maybe worth checking out for your use cases.

Immediate mode was certainly a different paradigm to wrap my head around, but so far I haven't found anything I couldn't accomplish with egui, including some fairly complex applications like https://timschmidt.github.io/alumina-interface/

Re: Upcoming Rust language features for kernel development

#34

Post by ogoffart »

timschmidt wrote: post #30
ogoffart wrote: post #24

Earlier quoted context omitted.

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

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

Re: Upcoming Rust language features for kernel development

#35

Post by timeon »

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.

> for everything else on userspace compiled managed languages are a much better option

Except for thread safety.

Re: Upcoming Rust language features for kernel development

#36

Post by timeon »

cosmic_cheese wrote: post #32
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.

Indeed. Last I knew all the Rust UI libraries were declarative and/or immediate mode, both of which have their place but I’m not convinced that they’re suitable in all situations. Sometimes you need a boring “old style” imperative UI framework with deep toolbox of capable widgets (think AppKit, win32, etc), but that’s notably absent in the Rust world.

How far from "old style" is Slint?

Re: Upcoming Rust language features for kernel development

#37

Post by timschmidt »

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

I appreciate the answer, and you taking time to write up your thoughts on it. Your point about the GUI builder working with the DSL is noted. In the egui RAD builder, I am manipulating structs which describe the UI (and which can be exported / imported as JSON) prior to code generation, which amounts to something similar. I still feel I have to context switch less, the back-and-forth is of more concern to me than learning an additional language.

That said, great work! There's plenty of room in the language for more than one solution!

Re: Upcoming Rust language features for kernel development

#38

Post by pjmlp »

timeon wrote: post #35
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 Except for thread safety.

Fearless concurrency, is only fearless for a very fine grained version of it.

In memory resources shared among threads.

Turns out threads also may share resources like out-of-process files, memory mapped regions, shared memory, databases, distributed transactions,.... where the Send and Sync traits is of no help.

Also you happen to forget Haskell has a Software Transactional Memory, and Swift also has similar protocols since version 6, and effects are a thing in OCaml, Scala, Koka, while languages like Dafny, Koka and Idris also provide similar capabilities via proofs.

Re: Upcoming Rust language features for kernel development

#39

Post by adwn »

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.

> 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 easy parallelization with statically guaranteed thread-safety. But hey, who needs this in the age of multicore CPUs?

Post reply on HN