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

201–210 of 279 posts

Re: Advice for the next dozen Rust GUIs

#201

Post by OJFord »

raphlinus wrote: post #128
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…

That's fair. The main reason Tauri isn't higher on my radar is that if you're going to make an app based on the web technology stack, why not just use Electron? The tooling is mature, there's lots of knowledge, and you can use Rust modules (through wasm) easily enough. I suppose it depends on the actual use case, I'm sure there is a niche for Tauri, but it doesn't intersect use cases I'm interested in particularly.

If someone into or getting into rust asked me 'how can I make a cross-platform app like with Electron', I would definitely say 'Tauri'; not 'actually you can use Electron with rust modules (through wasm) easily enough'.

Unless perhaps they're also big into the JS ecosystem anyway. That 'mature tooling' you mention is npm/yarn/etc. stuff; Tauri's is cargo.

Re: Advice for the next dozen Rust GUIs

#202

Post by nyanpasu64 »

msbarnett wrote: post #95
melony wrote: post #65

Earlier quoted context omitted.

The problem is that you can't even build data structures from introductory algos in Rust without pulling your hair out. No linked lists, no graphs.

That’s really only a problem if you spend a significant amount of time trying to “build data structures from introductory algos” without reaching for unsafe, though. If you find it easy to build a linked list or graph in C, you can do it just as easily in Rust — use unsafe, and you have your easy linked list, with exactly as much safety as it had in C. Sure, it’s more challenging to build a fully memory and thread sa…

The problem is that unsafe data structures are often less safe (harder to avoid UB) than in C, because in the presence of pointer aliasing and cycles (found in unsafe data structures including BTreeMap's node.rs https://doc.rust-lang.org/src/alloc/collections/btree/node.r...), Stacked Borrows places strict conditions on constructing &mut T (they invalidate some but not all aliasing *const T). And the user of an owning or intrusive linked list generally expects to receive &mut T, which is not always safe to construct because of Stacked Borrows. In fact, Gankra, a major contributor to unsafe Rust libraries, standards, and documentation, doesn't solve this problem through axiomatic reasoning, but instead an "oversimplified" "heuristic" (IMO hopes and prayers): https://rust-unofficial.github.io/too-many-lists/fifth-stack... (written 2022-01).

In practice, I find that unsound libraries frequently get written and used unknowingly in the wild. I've commented on this earlier at https://news.ycombinator.com/item?id=31897503.

In short, I believe that Stacked Borrows places unreasonable and unattainable requirements on authors of unsafe structures and algorithms, which serve as the foundation for practically all safe code (outside of the vanishingly rare case of code operating on tree-shaped fixed-size variables allocated solely on the stack, and never creating aliased mutable pointers).

Re: Advice for the next dozen Rust GUIs

#203

Post by tjoff »

pjmlp wrote: post #191
tjoff wrote: post #184

Earlier quoted context omitted.

I'd argue a GC is an order of magnitude bigger compromise though. And that even before considering performance.

Only when disregarding that many languages with GC capabilities, also offer value types and features for manual memory management.

Don't really see the appeal for that, seems like it leads to more fragmentation and very few benefits.

Re: Advice for the next dozen Rust GUIs

#204

Post by kristiandupont »

nyanpasu64 wrote: post #200
kristiandupont wrote: post #190

Earlier quoted context omitted.

I struggle to understand what you are saying here. What do you mean when you say "this memoization is now required for the correct functioning of the app"? I agree that there can be some issues with scroll restoration in routing, but it doesn't seem like a big issue to me and certainly doesn't seem to reveal some fundamentally flawed architecture.

Haven't written React, but it relies on memoization to preserve hidden state (like text carets and item scrolling) not tracked by your application. If you change the tree structure of your GUI (add/remove/move elements), and don't give scrollable UI items a key if they move, React will delete the scrollable DOM element and create a new one scrolled to the top, losing the user's scroll progress. The same goes for text…

Again, I am not sure if I am just misunderstanding something but that doesn't sound right to me.

>it relies on memoization to preserve hidden state

It relies on the DOM to keep that state. It's not hidden, you are just not forced to deal with it or think about it.

>If you change the tree structure [...] and don't give scrollable UI items a key if they move, React will delete the scrollable DOM element [...]

Yes, if you have an array of elements, you need to give them a unique identifier. This is a fundamental property of any diff-algorithm which the virtual DOM relies on. I don't think that is unreasonable, and IMO it is not something that adds significant cognitive load.

React definitely has quirks and especially optimizing for performance can be quite complex. But out of all the GUI frameworks I have tried (including Win32, WinForms and GTK as well as other web ones), React is the most intuitive to me.

Re: Advice for the next dozen Rust GUIs

#205

Post by pjmlp »

lewisjoe wrote: post #134

I like how the ecosystem around Kotlin has approached the problem. 1. The language itself has a way of introducing compiler plugins that lets you express your own tree structures in a succint syntax (comparable to macros in Rust I guess) 2. Then they figured out most UIs are trees and came up with a Flutter-like UI tree declaration API with react-like re-renders. Thus Android Compose was born! This went mainstream be…

Meaning Android team, no ecosystem to speak of.

There are even ADB episodes speaking about all those steps.

Re: Advice for the next dozen Rust GUIs

#206

Post by nyanpasu64 »

kristiandupont wrote: post #204
nyanpasu64 wrote: post #200

Earlier quoted context omitted.

Haven't written React, but it relies on memoization to preserve hidden state (like text carets and item scrolling) not tracked by your application. If you change the tree structure of your GUI (add/remove/move elements), and don't give scrollable UI items a key if they move, React will delete the scrollable DOM element and create a new one scrolled to the top, losing the user's scroll progress. The same goes for text…

Again, I am not sure if I am just misunderstanding something but that doesn't sound right to me. >it relies on memoization to preserve hidden state It relies on the DOM to keep that state. It's not hidden, you are just not forced to deal with it or think about it. >If you change the tree structure [...] and don't give scrollable UI items a key if they move, React will delete the scrollable DOM element [...] Yes, if y…

> This is a fundamental property of any diff-algorithm which the virtual DOM relies on. I don't think that is unreasonable, and IMO it is not something that adds significant cognitive load.

I think it's a leaky abstraction nonetheless, regardless if it causes issues in practice. But if it's not a significant issue to users, that's fine; personally I'd prefer to work in UI frameworks that avoid redundant diffing work by design (outside of cases like lists where it's difficult to avoid).

Re: Advice for the next dozen Rust GUIs

#207

Post by sandyarmstrong »

pjmlp wrote: post #196
favorited wrote: post #21

> On macOS ... going forward, it’s likely that new capabilities and evolutions of the design language will be provided for the latter [SwiftUI] but not the former [AppKit]. I think this is vastly over-stating the technical churn of UI development on macOS. While we're definitely seeing new UI toolkits introduced that are Swift-only (like the new Charts.framework[0]), nearly every Mac app Apple ships is written using…

Apple clearly stated at WWDC 2022, that the best days of Objective-C and AppKit/UIKit are behind them, they even had a slide for it in case there were any doubts.

Yup. Even the "What's new in AppKit?" talk pushed using SwiftUI for things like Settings due to controls only available in SwiftUI.

Re: Advice for the next dozen Rust GUIs

#208

Post by mwcampbell »

password4321 wrote: post #141
mwcampbell wrote: post #2

I'm the main developer of the AccessKit [1] project mentioned in this post. AMA. To preemptively answer one expected question, I know the project has been inactive for a while; I'm back to work on it in earnest starting this month. [1]: https://github.com/AccessKit/accesskit

Do you have a Patreon/whatever setup, since "this is the way" per baby Yoda?

Not yet. But Google is funding my work on AccessKit again this year. I'll write a blog post about that work later.

Re: Advice for the next dozen Rust GUIs

#209

Post by mattarm »

nyanpasu64 wrote: post #206
kristiandupont wrote: post #204

Earlier quoted context omitted.

Again, I am not sure if I am just misunderstanding something but that doesn't sound right to me. >it relies on memoization to preserve hidden state It relies on the DOM to keep that state. It's not hidden, you are just not forced to deal with it or think about it. >If you change the tree structure [...] and don't give scrollable UI items a key if they move, React will delete the scrollable DOM element [...] Yes, if y…

> This is a fundamental property of any diff-algorithm which the virtual DOM relies on. I don't think that is unreasonable, and IMO it is not something that adds significant cognitive load. I think it's a leaky abstraction nonetheless, regardless if it causes issues in practice. But if it's not a significant issue to users, that's fine; personally I'd prefer to work in UI frameworks that avoid redundant diffing work…

This got me reading up on leaky abstractions. Wikipedia credits https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... for the term, where he claims: "All non-trivial abstractions, to some degree, are leaky."

If leaky abstractions are unavoidable, we're left with debates about which leaky abstractions are justifiable given the constraints and goals of the design.

Re: Advice for the next dozen Rust GUIs

#210

Post by curun1r »

raphlinus wrote: post #128
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…

That's fair. The main reason Tauri isn't higher on my radar is that if you're going to make an app based on the web technology stack, why not just use Electron? The tooling is mature, there's lots of knowledge, and you can use Rust modules (through wasm) easily enough. I suppose it depends on the actual use case, I'm sure there is a niche for Tauri, but it doesn't intersect use cases I'm interested in particularly.

AIUI, the major difference between the two is that Tauri uses the system’s WebView while Electron bundles a specific version of Chromium. That means Tauri will have a number of performance advantages at the cost of not being able to target a specific browser.

Still, the “why not use Electron?” answer is that Electron is much more hostile to the user…much larger download size, slower startup and increased memory usage. With Rust valuing zero-cost abstractions, Tauri comes a lot closer to that ethos than Electron.

Post reply on HN