[timschmidt]

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

[pjmlp]

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

[timschmidt]

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, but I find C++ much more of a pain to work with than Rust.

[ogoffart]

Regarding Rust GUI framework, there is also Slint https://slint.dev

(Disclaimer: I'm one of the Slint developers.)

[timschmidt]

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?

[ogoffart]

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

[codedokode]

I don't think the DSL is any good. It looks weird (like a mix of CSS and classes), and it has a side effect of locking the user to a specific product.

In your article, you mention that an imperative code in Rust looks more complicated, but this can be fixed by adding an "object tree" syntax to Rust, that allows creating trees of objects and link them like this:

    VBox margin=10:
        Label text=label_text 
        Button label="OK" onclick=on_ok_clicked

This syntax could be used not only for UI, but for describing configuration, database tables and many other things. I think it would be better solution than a proprietary language.

Also I think it would be better if GUI could be drawn in the editor, it would allow to use lower paid developers without expensive computer science education for making UI.

[timschmidt]

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!

[onionisafruit]

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

[yencabulator]

Slint is not a great option:

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

[shakow]

God forbid a company plays the GPL rules fair and square...

[yencabulator]

Even FSF makes their central libraries LGPL not GPL.

[pjmlp]

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

[timschmidt]

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

[mdhb]

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.

[johnisgood]

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.

[timschmidt]

Sounds great for the Dart people. But unrelated to correcting misinformation about Rust. I'm not opposed to whatever language folks want to use. Just out here hacking in Rust because it suits my particular needs. And finding that it's enjoyable to hack GUIs as well as firmwares in.

[mdhb]

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.

[timschmidt]

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.

[izacus]

One week of hacking makes every library look good, but have you shipped actual product that other people widely use with Rust GUI yet? What was the experience there and - most importantly - what were the downsides?

[timschmidt]

I've been working with egui for a couple years. Written maybe a dozen applications with it doing various things from image manipulation to 3D graphics. As I've said elsewhere in the thread, I haven't run into anything I wasn't able to accomplish with it.

Immediate mode has it's detractors, but in practice I've found it remarkably flexible, the resulting code relatively clean, and egui gets out of the way when I want to do something like blit fast graphics to a memory mapped area of the screen. Responses have been positive.

[mamcx]

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

[pjmlp]

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.

[mamcx]

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.

[0x457]

Depends on your definition of good.

I think Swift (and even ObjC) is perfect for AppKit & UIKit. I think those frameworks are pretty good and I like using them. Languages have great integration, Swift literally made around them. Those toolkits have great integrations with the macOS.

I find C# a pretty nice language for GUI, I assume it has good (maybe not great) integration with at least one of MS GUI toolkits.

I find Rust good for GUI, but right now story is meh. Wrapper style frameworks always suffer from Rust not being whatever it wraps. Pure Rust framework miss a lot of features compared to wrapper frameworks.

[afishhh]

> Rust exceling at GUIs is a bit of a strech.

I strongly agree with this. In particular the Rust GUI libraries I've looked at have text layout / rendering that is nowhere near what should be considered adequate today (imo).

For example egui:

- It doesn't do any bidi reordering.

- It also doesn't do any font fallback so even if you didn't need bidi you can't render many languages without first acquiring an appropriate font somehow.

- Complex shaping is nowhere to be seen either.

- egui's italics look really terrible and I'm not sure why since I can't believe even synthesized ones have to look that bad.

CSS has been doing this for years and it's been doing it very well. So I am kind of disappointed that we don't have equally powerful tools in the general Rust ecosystem. Even just considering text layout / rendering libraries, only `cosmic-text` has an API that is somewhat in the right direction[1], but even it fails simply because I don't see a way to insert a button (block element) in-between the text[2].

Note that I'm not just hating on egui here, egui is amazing. Afaict it is the most complete GUI library for Rust and it's great to be able to make GUIs this easily. However I can't just not point out that it is, in fact, not perfect and doesn't truly "excel" at GUIs.

Also I have no idea how inline layout looks in other established GUI libraries like GTK and Qt so maybe I'm complaining about something that is not available most places outside a browser. If anyone knows, it would be interesting to learn how well they compare here.

[1] CSS inline layout is so complex that even this is a decent achievement, since it is not reasonable to expect most CSS features out of new Rust libraries with a significant time disadvantage.

[2] This is non-trivial because bidi reordering should happen on the whole paragraph not only on both sides of the button, so the inline layout API must handle non-text blocks in text.

[timschmidt]

This is a detail oriented list of real issues, which is wonderful! ChatGPT found open issues in the egui Github for each of your problems, so they're known about and being worked on.

However, it seems like most of the other UI toolkits discussed here, even in other languages, suffer similar issues. Which points to the difficulty of the problems. Consequently, I don't have any problem praising egui and Rust alongside. They're great! And even great can always get better! :)

[IshKebab]

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.

[anarki8]

I wouldn't say it's bad at GUIs either. There are some nice libraries like Iced and Slint. Some even have good accessibility support like egui.

There is a full-fledged DE written in Rust that uses Iced: https://en.wikipedia.org/wiki/COSMIC_(desktop_environment)

[cosmic_cheese]

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.

[timschmidt]

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/

[timeon]

How far from "old style" is Slint?

[cosmic_cheese]

From a quick glance, about as far as the other Rust toolkits. Looks declarative with with a relatively small number of more basic widgets (a lot of custom widget code is necessary), as opposed to e.g. AppKit which is imperative and comes with a great number of rich widgets that are ready to use out of the box.

[WD-42]

The GTK bindings are fine.

[discreteevent]

> Rust is a rare gem that excels at both.

This can be true but it can still be the case that a managed language is even better at one of them.