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

61–70 of 279 posts

Re: Advice for the next dozen Rust GUIs

#61

Post by raphlinus »

aaaaaaaaaaab wrote: post #57
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 Why exactly? What are the current state of the art UI toolkits leaving on the table performance-wise?

I'll have a lot more to say about this as I gather quantitative performance data. But it's a good question. I expect the big wins are: fast 2D (vector with blends and so on) rendering with compute shaders, multithreaded creation of expensive resources like image decompression and text layout, pushing incremental reactivity all the way from app logic to GPU (as opposed to needlessly redoing work), and of course just using a fast, non-GC language.

Re: Advice for the next dozen Rust GUIs

#62

Post by the_duke »

filleokus wrote: post #50
CrimsonVoid wrote: post #40

I know this is going to be a controversial opinion considering how much everyone seems to love Rust, but does anyone else find Rust incredibly painful to work with, even for simple tasks? Like I'm no stranger to unmanaged languages, and to some extent I cut my teeth on C, but doing anything with Rust always feels like the most aggravating exercise in needless verbosity and the "Lombok problem" doesn't help either. (F…

I remember reading (on HN I think) that coding in Rust is like playing some kind of intricate puzzle game. Tricking the compiler into accepting your code. You feel smart when it works and challenged when it complains. I personally like that aspect, at least for now. On the other end of the spectrum I would say Go is, with its lack of "advanced" or functional language features and sans-syntactic-sugar straight forward…

> coding in Rust is like playing some kind of intricate puzzle game. Tricking the compiler into accepting your code

That is mostly only true for very early beginners.

There are certain patterns you have to learn and understand, especially for developers not accustomed to thinking about lifetimes ( which applies to most developers that only have experience with GC languages).

And sometimes you do have to battle the compiler, even with experience.

But most of that goes away pretty quickly once the language clicks for you.

After that Rust can still feel restrictive, but that's because there are very few languages that enforce as much correctness at compile time.

That very well can mean that Rust just isn't a good fit for certain domains - which is perfectly fine!

Re: Advice for the next dozen Rust GUIs

#63

Post by moonchild »

pcwalton wrote: post #28
modeless wrote: post #16

Earlier quoted context omitted.

The best GPU accelerated text rendering I know of is https://sluglibrary.com/ . Not based on distance fields. Unfortunately not open source, though it is a one-man project. Maybe someday one of the big tech companies will pay him a whole ton of money to open source it.

For most text rendering in the 2D UI use case, I'm not sure there is that much to solve anymore. Aggressive caching of rendered glyphs solves almost all the problems in practice. From what I can tell, Slug is targeted at games and 3D, where there are still interesting problems, but those aren't the 2D UI case.

Even in 2-d, it is nice to have smooth zoom in/out. The only way to do this that I know of that doesn't compromise on quality is to re-render every frame, and the only way I know to do that fast is to use the gpu. I believe pathfinder can do it (correct me if I'm wrong). I know I'm working on something that can do it too.

Moving a bit farther from the strictly 'text' realm there are authoring tools for vector graphics, where you would like to be able to view the changes you make in real time. CPU can do it (since it's probably the only complex thing onscreen, and changes are likely localised anyway if you really need the extra cycles), but GPU can do it better.

Re: Advice for the next dozen Rust GUIs

#64

Post by favorited »

tmpfs wrote: post #42
hardwaresofton wrote: post #32

Bit of a hot take, but I basically expect that most new Rust GUI projects will be written in Tauri before long. It works on multiple platforms, and is flexible, and it's easier to find off the shelf pieces due to the web technology involved, and it's lighter than Electron. It's a no-brainer for me (and others, I think) if I'm starting a new GUI desktop project.

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

Re: Advice for the next dozen Rust GUIs

#65

Post by melony »

Starlevel001 wrote: post #47
CrimsonVoid wrote: post #40

I know this is going to be a controversial opinion considering how much everyone seems to love Rust, but does anyone else find Rust incredibly painful to work with, even for simple tasks? Like I'm no stranger to unmanaged languages, and to some extent I cut my teeth on C, but doing anything with Rust always feels like the most aggravating exercise in needless verbosity and the "Lombok problem" doesn't help either. (F…

Rust is a clever language, which wrecks havoc on people's programming ego by making them very inclined to try and write clever code. But if you avoid trying to be really annoying with the type system like the majority of the ecosystem is, and slap Arc/RefCell/heap allocations everywhere, the language turns back into a high-level language again. Unfortunately, stepping outside the realm of ``core`` and ``alloc`` and `…

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.

Re: Advice for the next dozen Rust GUIs

#66

Post by jreese »

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…

On the flip-side, it's worth keeping in mind where the puck is heading. Every "new" macOS app from Apple (eg, Shortcuts, System Settings, and even recent refreshes of old apps) has been written in either SwiftUI or Catalyst. A bunch of these still link to AppKit here and there, but it seems pretty clear that no new developement is breaking ground with AppKit.

Similar to the Carbon/Cocoa split, I'm sure we'll see AppKit supported well into the future, especially since we just passed the latest major architecture transition. But that doesn't mean AppKit isn't a dead end.

Re: Advice for the next dozen Rust GUIs

#67

Post by astrange »

favorited wrote: post #39
jolux wrote: post #26

Earlier quoted context omitted.

Aren't App Store and Photos Mac Catalyst apps?

Nope! Both are fully native macOS apps, at least on the version of Monterey that I'm running. You can examine which frameworks a binary links by running `otool -l /System/Applications/Photos.app/Contents/MacOS/Photos`. Traditional macOS Cocoa apps will link AppKit, while Catalyst apps will link UIKit. For example, if you run that command with a Catalyst app (e.g., Messages or Maps), you'll see that those apps link ag…

Photos on the Mac actually uses their own private reimplementation of UIKit called UXKit from before Catalyst.

(So does Twitter on the Mac, which was written by a developer on the original iPhone.)

Re: Advice for the next dozen Rust GUIs

#68

Post by jolux »

favorited wrote: post #39
jolux wrote: post #26

Earlier quoted context omitted.

Aren't App Store and Photos Mac Catalyst apps?

Nope! Both are fully native macOS apps, at least on the version of Monterey that I'm running. You can examine which frameworks a binary links by running `otool -l /System/Applications/Photos.app/Contents/MacOS/Photos`. Traditional macOS Cocoa apps will link AppKit, while Catalyst apps will link UIKit. For example, if you run that command with a Catalyst app (e.g., Messages or Maps), you'll see that those apps link ag…

Interesting, I thought I had heard that App Store was Catalyst now for some reason.

Re: Advice for the next dozen Rust GUIs

#69

Post by modeless »

moonchild wrote: post #63
pcwalton wrote: post #28

Earlier quoted context omitted.

For most text rendering in the 2D UI use case, I'm not sure there is that much to solve anymore. Aggressive caching of rendered glyphs solves almost all the problems in practice. From what I can tell, Slug is targeted at games and 3D, where there are still interesting problems, but those aren't the 2D UI case.

Even in 2-d, it is nice to have smooth zoom in/out. The only way to do this that I know of that doesn't compromise on quality is to re-render every frame, and the only way I know to do that fast is to use the gpu. I believe pathfinder can do it (correct me if I'm wrong). I know I'm working on something that can do it too. Moving a bit farther from the strictly 'text' realm there are authoring tools for vector graphic…

Yeah, existing techniques work fine if you want to make something similar to existing systems. But it's a shame to write a whole new GUI library and still have the same old limitations. Zooming is underused in existing systems, probably related to the fact that it's hard to make it work well with commonly used techniques.

Re: Advice for the next dozen Rust GUIs

#70

Post by jolux »

astrange wrote: post #67
favorited wrote: post #39

Earlier quoted context omitted.

Nope! Both are fully native macOS apps, at least on the version of Monterey that I'm running. You can examine which frameworks a binary links by running `otool -l /System/Applications/Photos.app/Contents/MacOS/Photos`. Traditional macOS Cocoa apps will link AppKit, while Catalyst apps will link UIKit. For example, if you run that command with a Catalyst app (e.g., Messages or Maps), you'll see that those apps link ag…

Photos on the Mac actually uses their own private reimplementation of UIKit called UXKit from before Catalyst. (So does Twitter on the Mac, which was written by a developer on the original iPhone.)

The new Twitter app does use Catalyst though.
Post reply on HN