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

21–30 of 240 posts

Re: Upcoming Rust language features for kernel development

#21

Post by mdhb »

timschmidt wrote: post #18
mdhb wrote: post #17

Earlier quoted context omitted.

No I get all that, but to the parent comments point however, there’s no way in hell I would ever pretend for a moment that one is as straightforward as the other and it’s no longer a choice between Rust and C++ both of which add a lot of complexity to a scenario where it offers very little benefit.

Over the years, I've found that the complexity is there whether or not it's been papered over by a runtime. It's wonderful to forget about, until it's not. Some applications may never run into the limitations imposed by abstracting it away, but others run into them quickly. "There ain't no such thing as a free lunch" as the saying goes.

To which the counter argument I guess would be.. there’s no sense in trying to solve for some abstract future set of problems that the vast majority of people are never going to have ahead of time on the off chance you’re one of them.

That too requires a substantial investment of time and resources.

I think in a more pragmatic sense too that you can form a very good understanding on if you’re going to have weird special requirements just from looking at what others have done with the same tools in similar situations before you.

Re: Upcoming Rust language features for kernel development

#23

Post by timschmidt »

mdhb wrote: post #21
timschmidt wrote: post #18

Earlier quoted context omitted.

Over the years, I've found that the complexity is there whether or not it's been papered over by a runtime. It's wonderful to forget about, until it's not. Some applications may never run into the limitations imposed by abstracting it away, but others run into them quickly. "There ain't no such thing as a free lunch" as the saying goes.

To which the counter argument I guess would be.. there’s no sense in trying to solve for some abstract future set of problems that the vast majority of people are never going to have ahead of time on the off chance you’re one of them. That too requires a substantial investment of time and resources. I think in a more pragmatic sense too that you can form a very good understanding on if you’re going to have weird spec…

> there’s no sense in trying to solve for some abstract future set of problems that the vast majority of people are never going to have

> That too requires a substantial investment of time and resources.

The discussion has gotten to be pretty abstract at this point. To get back to concrete examples, the egui RAD builder I've been hacking on worked on day 1, first commit. It's been a joy to put together, and no more difficult than building GUI apps with any other toolkit I've worked with. Which causes me to question your statements about additional complexity. You can dig deep and do dark magic with Rust if you want, but you can also treat it like any high level language and get things done quickly. That's part of what makes it a rare gem to me.

Some folks don't like dealing with strict types, or with the borrow checker, but I find that the errors they illuminate for me would have been similarly serious in other languages which lacked the tooling to highlight them. Which adds to my appreciation of Rust.

Re: Upcoming Rust language features for kernel development

#24

Post by ogoffart »

timschmidt wrote: post #11
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.

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

Re: Upcoming Rust language features for kernel development

#25

Post by [deleted] »

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.

[deleted]

Re: Upcoming Rust language features for kernel development

#26

Post by johnisgood »

mdhb wrote: post #13
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…

But that’s no longer the choice you need to make. Ubuntu themselves have said for a couple of years now that every new GUI app they make natively for Linux is going to be Flutter and dedicated a bunch of engineers to the project to make sure it’s a first class citizen. Beyond that, Dart / Futter are truly an absolute pleasure to use for that use case.

Yeah, I do not know Dart / Flutter much, but if I had to choose, I would either pick that, or wxWidgets, or even Tcl/Tk, but not Rust.

Re: Upcoming Rust language features for kernel development

#27

Post by simonask »

Tuna-Fish wrote: post #9
PoignardAzur wrote: post #4

> The final design, taking inspiration from C++, would be a form of guaranteed optimization, where constructing a new value and then immediately moving it to the heap causes it to be constructed on the heap in the first place. Note that there's some discussion about the name of that proposal, because "optimization" gives the wrong idea (that it's optional or could depend on the backend).

I'm probably misunderstanding the complexity of the problem, but wouldn't this be solvable by just defining the right calling convention? "Any structures larger than x, or any structures marked with a marker type, are returned by the caller providing an outref to a buffer with correct size, and the callee directly writes the structure into that buffer." Then you could just write normal code like fn initialize() -> A…

The missing piece is that it would still force you to make even larger types in many cases, such as `Result`.

Essentially the problem is composability. If you are building a large type from a sequence of other large types, and one or more step is fallible, the normal return ABI breaks down very quickly.

Re: Upcoming Rust language features for kernel development

#28

Post by timschmidt »

pjmlp wrote: post #19
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…

How does it handle localization and assistive technologies, UI/UX tooling for designers, 3rd party component ecosystem?

egui works with AccessKit to provide accessibility support. I haven't added anything explicitly to the RAD builder for it yet. Great idea!

Re: Upcoming Rust language features for kernel development

#29

Post by sesm »

PoignardAzur wrote: post #4

> The final design, taking inspiration from C++, would be a form of guaranteed optimization, where constructing a new value and then immediately moving it to the heap causes it to be constructed on the heap in the first place. Note that there's some discussion about the name of that proposal, because "optimization" gives the wrong idea (that it's optional or could depend on the backend).

Why make this a behind-the-scene optimization instead of just introducing `new`? That would make things much more clear for everyone.

Re: Upcoming Rust language features for kernel development

#30

Post by timschmidt »

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

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?
Post reply on HN