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

181–190 of 279 posts

Re: Advice for the next dozen Rust GUIs

#181

Post by nguyenkien »

favorited wrote: post #64
tmpfs wrote: post #42

Earlier quoted context omitted.

I think you are right about this with the one huge problem from my point of view being the text rendering on Windows. This is of course a problem with the Webview implementation on Windows but it is so awful it makes me want to use something else instead. Note this is not a reflection on Tauri which I think is awesome but Microsoft really should fix it.

Is there something blocking Tauri from switching to WebView2 on Windows? It's based on Chromium, so I assume most of the legacy web view issues would be irrelevant. IIRC, WebView2 is supported going back to Windows 7...

Tauri use webview2 on Windows

Re: Advice for the next dozen Rust GUIs

#182

Post by [deleted] »

joshka wrote: post #43
raphlinus wrote: post #27

Earlier quoted context omitted.

“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” — Antoine de Saint-Exupéry I will one hundred percent agree with you that my approach is not a good one if you want a pretty good GUI in a reasonable amount of time. For that, an incremental approach, especially adapting some existing successful design, woul…

>So I'm pretty comfortable with my approach. And hey, next time you're in the Bay Area (or perhaps when I'm in your neck of the woods), lemme buy you beer and we can talk about why it gives you satisfaction to dump on other people's work. I love this response - stealing it :)

[deleted]

Re: Advice for the next dozen Rust GUIs

#183

Post by pornel »

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…

UIs can spawn jobs in the background, but that's an explicit thing programmer has to do, and evidently they forget all the time. It took Apple over a decade to mostly fix "beachballing" problems plaguing Finder.

Another problem that may be Cocoa-specific is that it can hook UI-changing observers to objects, and then these objects become unsafe to use in multi-threaded programs (including those background jobs you should be using!)

Re: Advice for the next dozen Rust GUIs

#184

Post by tjoff »

amelius wrote: post #175
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.

I'd argue a GC is an order of magnitude bigger compromise though.

And that even before considering performance.

Re: Advice for the next dozen Rust GUIs

#185

Post by ratww »

jakear wrote: post #49
raphlinus wrote: post #27

Earlier quoted context omitted.

“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” — Antoine de Saint-Exupéry I will one hundred percent agree with you that my approach is not a good one if you want a pretty good GUI in a reasonable amount of time. For that, an incremental approach, especially adapting some existing successful design, woul…

> it will be a UI toolkit capable of performance completely untouchable by the existing state of the art Could you give an example of an application where the bottleneck is UI code? In my experience the bottleneck is always either disk or network. Not trying to bash you, genuinely curious.

There's plenty of apps that we developers use daily that fall into that. Apps like Teams, Slack and Jira can feel incredibly slow to a lot of people, even with everything already in memory and not waiting for anything from the network or disk. Typing messages, changing tabs, going to read a notification... Facebook sometimes takes a second to show characters you typed in a reply, and the characters often show up out of order (also zero network activity during it). A lot of complex WYSIWYG editors are also incredibly heavy, while simpler ones aren't.

Sure, that might be technically a bandwidth problem: in this case probably RAM. It is solvable with faster computers/faster RAM. But it's slower or at least the same speed as it was in the past with slower machines. Since hardware got better, it has got to be something different in the software side.

And it's not even about difficult things like Unicode Glyphs and Emojis, which are common canned responses when anyone says that software "is slower than N years ago". Those things are handled by the OS, not by Jira. And there are super fast apps that make use of them.

Re: Advice for the next dozen Rust GUIs

#186

Post by [deleted] »

tjoff wrote: post #184
amelius wrote: post #175

Earlier quoted context omitted.

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

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

[deleted]

Re: Advice for the next dozen Rust GUIs

#187

Post by amelius »

tjoff wrote: post #184
amelius wrote: post #175

Earlier quoted context omitted.

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

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

Yes, so use Rust for all your tree-shaped programming problems.

And a GC'd language for everything else.

I know if you're holding a hammer it's difficult to not see everything as a nail ...

Re: Advice for the next dozen Rust GUIs

#188

Post by stephc_int13 »

tayistay wrote: post #60
stephc_int13 wrote: post #48

Earlier quoted context omitted.

To be frank, I think that the kind of work you are doing is necessary. In my opinion GUI is not yet something I would consider to be a "solved problem". Both from the API perspective and the rendering side, and compute shaders are indeed extremely promising and could be something close to an end-game in this space. This is why I read your articles. And I have absolutely zero interest in dumping on your work, but I ha…

What, specifically do you think the flaws are? I think if you're going to make such criticism, it helps to give actionable specifics (i.e. constructive criticism). How is the approach discouraging to other devs?

I think that people who manage to achieve "impossible" tasks tend to be overly optimistic (and naïve) at first, consciously or not, this is a good trick to fuel their own motivation and that of others.

On the contrary, knowing/talking too much about the difficulties can quickly kill the fun and motivation.

He should talk about how great the end-goal will be and why it is important.

Re: Advice for the next dozen Rust GUIs

#189

Post by pjmlp »

pornel wrote: post #180
pohl wrote: post #36

Earlier quoted context omitted.

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.

Swift Rust 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 gre…

It has partial support for it, and Swift 6.0 roadmap has a plan for it.

https://www.infoq.com/news/2020/01/swift-6-vision/

Additionally its async/await and distributed actors story is much better than Rust's current story.

Re: Advice for the next dozen Rust GUIs

#190

Post by kristiandupont »

nyanpasu64 wrote: post #130
jchw wrote: post #29

Earlier quoted context omitted.

The thing is, there do exist UI frameworks that prefer composition over inheritance and strictly tree shaped components where data only flows one way: they're all the rage on the web. And that's great, because they give plenty of useful insight into things that work and don't work when designing UI frameworks this way. To be fair, it's not exactly like nobody realized this. More than one Rust desktop UI framework is…

I don't like React: https://news.ycombinator.com/item?id=31981947 > In Cocoa, scroll position is part of the view's state, a mere property of the view. This is simple because the UI itself is stateful. > In React, scroll position is typically not part of the state from which we project the view. Instead this state is attached to the projection itself (e.g. a HTML node) and we are dependent on the "Memoization Map" to…

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.

Post reply on HN