Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advice for the next dozen Rust GUIs

raphlinus.github.io

Post reply on HN
Print view View original

171–180 of 279 posts

Re: Advice for the next dozen Rust GUIs

#171

Post by kaba0 »

cjohansson wrote: post #160
pornel wrote: post #17

The background for this is that most existing UI toolkits are a poor fit for Rust. Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time. Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references. Rust prefers everything thread-safe, but many U…

Thank you for the context, this also explains why most UIs gets broken / stuck at times. Like spinners that never stops or buttons that stay disabled even though they should be enabled. Those kinds of issues happens every day even in Apple, Google and Meta products (a lot of economical power) so there must be a deeper structural cause for this and I think it boils down to that the UI frameworks used are inherently fr…

I wouldn’t say it is inherent, I think it has more to do with state management - some state is inherent to the component itself, but the separation is problematic. All too often business logic gets stored in the component and vice versa.

Re: Advice for the next dozen Rust GUIs

#172

Post by kaba0 »

armchairhacker wrote: post #101
jollybean wrote: post #96

Earlier quoted context omitted.

Most UI frameworks enforce a 'single thread' rule, i.e. one thread at a time touches the tree. Would this solve the problem?

yes there’s absolutely no need for UI to be multi-threaded. You can do stuff in the background but IMO multi-threaded UI is completely useless. You have an event loop where you poll for input => propagate changes => commit changes => rerender UI. Normally you might have poll => propagate => rerender, but when you delay the changes you can represent everything in a shared reference, and when commit them you have a sin…

Not really UI, but wasn’t one recentish game really performant due to it using Vulkan, but in a multi-threaded way? Not sure whether it would benefit traditional UIs though.

Re: Advice for the next dozen Rust GUIs

#173

Post by johnofthesea »

PoignardAzur wrote: post #170
malkia wrote: post #162

The elephant in the room for big CAD/CAM apps is dockable widgets, where (for me personally), the "standard" is how Visaul Studio does it. Even Qt, with it's built-in widgets is not enough (e.g. no multiple widgets/windows in non-main window), but there are some extensions/libraries/hacks to go around. Recently, few years ago, imgui got proper support for these too. And flutter has one or more design docs around it -…

Can you develop? I understand the term "dockable widgets", but I'm not sure I'm visualizing the same UI as you.

Something like Photoshop/Gimp panels I guess.

Re: Advice for the next dozen Rust GUIs

#174

Post by [deleted] »

veidr wrote: post #144
OJFord wrote: post #107

This seems to implicitly mean low-level GUIs, or GUI frameworks? The only mention of Tauri is 'tao the fork of winit used by'. The article opens: > A few times a week, someone asks on the #gui-and-ui channel on the Rust Discord, “what is the best UI toolkit for my application?” Unfortunately there is still no clear answer to this question. I would say if by 'UI toolkit for my application' you just want a way to make…

I find this omission weird, too. It seems to me that, maybe because of the situation described in this article, Tauri already has become, or at least is quickly becoming, the clear answer to this question. This article seems to be implicitly excluding Tauri from consideration, because the UI portion in Tauri is not "native" or even Rust-based. With Tauri, you write the whole app in Rust except the UI. (Technically, y…

[deleted]

Re: Advice for the next dozen Rust GUIs

#175

Post by amelius »

pornel wrote: post #17

The background for this is that most existing UI toolkits are a poor fit for Rust. Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time. Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references. Rust prefers everything thread-safe, but many U…

> Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references.

This is also the problem with closures. And why you can't do Haskell/Ocaml style functional programming in Rust.

Rust has the reputation of being fast, but if you force everything into a tree, you are making big compromises from the start.

Re: Advice for the next dozen Rust GUIs

#176

Post by pjmlp »

dragonwriter wrote: post #142
galangalalgol wrote: post #100

Earlier quoted context omitted.

I'm pretty sure the mismatch is just that the major ui frameworks were designed for oop languages, not that UI is inherently oo. As the gp said, react type frameworks play fine with languages that have no inheritance. It's just a matter of a few more coming along with the same paradigm(s).

> I’m pretty sure the mismatch is just that the major ui frameworks were designed for oop languages, not that UI is inherently oo I’m pretty sure you are right. It seems to me that both FRP and ECS models of UI are at least as good as OO models, and a lot more adaptable to Rust than conventional OO models. But GUIs and OOP grew up together and have been deeply wedded, so non-OO UI just isn’t how people are used to th…

COM has done quite well for Windows since VB 6 days.

Re: Advice for the next dozen Rust GUIs

#177

Post by amelius »

nine_k wrote: post #98
pornel wrote: post #17

The background for this is that most existing UI toolkits are a poor fit for Rust. Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time. Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references. Rust prefers everything thread-safe, but many U…

There's one "UI toolkit" that builds in top of immutable data structures, trees, and unidirectional data flow. It has also taken web UI development by storm. It's called React. I wonder if React-like approaches are going to work for Rust UI toolkits. They could even wrap some native controls, much like React does with DOM controls, or React Native with Android controls.

React is nice for high-level work. However, if you're writing e.g. a rich text editor from scratch it is probably not a good fit from an efficiency viewpoint.

Re: Advice for the next dozen Rust GUIs

#178

Post by pjmlp »

kaba0 wrote: post #166
jollybean wrote: post #133

Earlier quoted context omitted.

So that's a good point, but I'm not quite sure OO is the issue. Also - as you hint it's entirely unnecessary, I do actually believe OO is a natural match for UI because of the overlap between components. I think it's the fact in UI you have a big chunk of state, with references all over, and sometimes doing sort of 'circular references' ... Rust code starts to have a lot of the various Vec Rc Cell Box all over the pl…

> Rust code starts to have a lot of the various Vec Rc Cell Box all over the place Well, C and C++ also has all of these, with the former having it in a convention-only manner, where you have to learn what the author intended for every project. These are generic paradigms that are useful and often needed for low-level programs, and Rust makes their usage safe. What I do find problematic regarding rust is that people…

Additionally, those with support for value types can take advantage of optimizations without switching languages.

Re: Advice for the next dozen Rust GUIs

#179

Post by pjmlp »

pohl wrote: post #36
pornel wrote: post #17

The background for this is that most existing UI toolkits are a poor fit for Rust. Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time. Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references. Rust prefers everything thread-safe, but many U…

Swift is different from Rust, but it's more towards Rust's end of the spectrum. Sure, it has classes, but it's almost as if they're mostly there to aid in compatibility with Objective-C APIs like UIKit. SwiftUI builds UIs with value types and protocols like View. I wonder if something like SwiftUI would work well for Rust.

Visual designers and GUI components don't play well with borrow checker.

Re: Advice for the next dozen Rust GUIs

#180

Post by pornel »

pohl wrote: post #36
pornel wrote: post #17

The background for this is that most existing UI toolkits are a poor fit for Rust. Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time. Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references. Rust prefers everything thread-safe, but many U…

Swift is different from Rust, but it's more towards Rust's end of the spectrum. Sure, it has classes, but it's almost as if they're mostly there to aid in compatibility with Objective-C APIs like UIKit. SwiftUI builds UIs with value types and protocols like View. I wonder if something like SwiftUI would work well for Rust.

SwiftRust similarity is only superficial in syntax. Swift has full OOP with inheritance, allows shared mutable state, and doesn't have compile-time thread safety. It has been built for Cocoa interoperability from the start.

The clunky `Rc>` that Rust tries to get rid of from UI toolkits in Swift is just `Object`. Rust's undesirable case is the Swift's built-in default (that's not a criticism of Swift, ARC works great there, but these two languages have chosen very different trade-offs).

Post reply on HN