Live data from Hacker News

The state of building user interfaces in Rust

areweguiyet.com

131–140 of 156 posts

Re: The state of building user interfaces in Rust

#131

Everyone seems to be converging on React/Elm arch for UI. I saw a paper years ago for incremental lambda calculus ( https://inc-lc.github.io ) that I feel addresses the fundamental problem here more honestly. It's mostly intended for optimizing repeated computations after small changes to the inputs, but I think it applies nicely to UI. Our data model needs to be a change structure along with our UI model. We write a…

Incremental lambda calculus is a fascinating concept, I hadn't heard of it before.

A theory of changes for higher-order languages: incrementalizing λ-calculi by static differentiation - https://dl.acm.org/doi/10.1145/2594291.2594304

From the abstract, I get the impression it would require very granular atomic-level language transformations, that are only practical for languages that are designed from the ground up to support creating and applying such deltas. Rust and JavaScript/React seem overly complex for reducing down to that level of granularity, especially the latter for strictly typed and deterministic changes. Maybe a language like Haskell is more suitable, since I've heard that it (or a subset) can be compiled down to typed combinators as primitives.

> probably need a language with HKT

Ah, that sounds related to the thought above, that the technique may be best implemented at the level of language design. Does "HKT" mean "higher kinded types"? Closest I could find was a library for TypeScript: https://majorlift.github.io/hkt-toolbelt/

> _truly_ immediate mode framework where each widget is a pure function

It sounds like the "functional reactive" paradigm, which I think React is loosely based on and probably UI libraries like Imgui and others in Rust also. But none of them are "pure" like you describe because the languages they're built on are not pure all the way to the bottom. (Maybe Rust is, but it's likely too complex to practically "diff" and "patch" not only the data models but the running code incrementally, though I may be misunderstanding.)

Re: The state of building user interfaces in Rust

#132

Earlier quoted context omitted.

Does it allow you to do things like: take this font at 20px, outline it with a stroke of 2px, turn that stroke into a path, then use that path as a clipping mask, then render this image using that mask.

When you specify the stroke width of 2px and then turn it into a path, are you expecting the outline of the font to expand? Is the 2px stroke centered on the original glyph path, so 1px is "in" in the glyph and 1px is "out"? I take your question to basically mean "can it expand or shrink a path?" and "can it use a path as a clipping mask?" Or did I misunderstand and you want to only show the image within the 2px sliv…

Don't worry about the specifics, I'm just asking if it can do modern 2D graphics well.

Re: The state of building user interfaces in Rust

#133

The more interesting question is why we're not GUI yet. I have Thoughts on this, which I'll try to briefly summarize here. * It's a genuinely hard problem The state of GUI on Windows is a total mess, very disappointing considering the relative importance and resources that Microsoft has. SwiftUI was a success (Apple is uniquely good at this stuff), but the transition from Cocoa is still not complete. A large part of…

This is an excellent comment. Then I realized you're the same person who wrote the article I currently have open in the next tab. Advice for the next dozen Rust GUIs - https://raphlinus.github.io/rust/gui/2022/07/15/next-dozen-g...

Insightful point about how the struggle to converge on a well-designed UI paradigm is related to a larger question of how the industry is still experimenting and exploring the problem space, particularly:

> reactivity, which is at heart incremental computation

Another comment that caught my attention up-thread was talking about "incremental lambda calculus", which is the same question in different words. My impression was that ideally it needs a language-level solution to be able to support "diff" and "patch" not only on the data but the running code, perhaps built from primitives like continuations.

> feels to me a bit like async

Maybe part of the difficulty with reactive UI is fundamentally related to how the language "solves" async, for which there's still no real concensus on the best way to solve it.

Re: The state of building user interfaces in Rust

#134
post #128
post #97

Earlier quoted context omitted.

> a big attack surface Wdym? At least web apps are sandboxed by default in contrast to native.

Depends on which OS we're talking about.

Under which OS would a website not be sandboxed? It's the browser doing the sandboxing, not the OS.

Re: The state of building user interfaces in Rust

#135
post #31

Throwing in my vote... I've been doing everything with wasm-bindgen/web-sys, i.e. just doing my UIs in html, and for 99% that's what I'd want anyways. Web UIs are portable, remotely accessible, and don't require installation on each client. For the small percent that's left where speed is critical, I've just been using wgpu and wgsl-bindgen directly. I can't think of what I'd want a native UI solution for. And then h…

> I can't think of what I'd want a native UI solution for. And then having to deal with porting it to iOS, Android, Windows, Mac etc, dealing with app stores (3+?) submissions, developer fees, rejections

Not everything is yet another shitty b2c "app".

There are whole industries where cross-platform support is irrelevant, as paying customers just keep using Windows.

Re: The state of building user interfaces in Rust

#137
I believe Rust will never be a major player in GUIs.

As in other areas where business outcomes of a software is more important than efficient memory management. I don't like Electron, but its popularity just makes it obvious that nobody cares about RAM usage in the GUI area.

Re: The state of building user interfaces in Rust

#138
post #129

While part of the Windows crate, I think windows-reactor deserves explicit mention. https://github.com/microsoft/windows-rs/tree/master/crates/s... It's a react-style API for WinUI3 apps, meaning it's not trying to mimic the Windows LAF. It's merely a binding.

I would approach anything windows-rs with care, the team is the one responsible for killing C++/CX in name of C++/WinRT, and then leaving it half baked to go play with Rust and windows-rs. Nothing they said on stage at CppCon 2017 came to fruition. You're better off doing the UI in WPF and calling into Rust DLLs.

Makes sense, Microsoft doesn't have the best track record in supporting frameworks.

I myself have never worked with C++/CX or C++/WinRT. My Rust journey has been exclusively on POSIX systems, so seeing windows-reactor and getting a UI in a couple of lines is pretty cool.

I would never (at least not in its current state) recommend it for production though, as the crate containing reactor isn't even on crates.io.

Could you share some of the promises made that were abandoned? (I just realized that question sounds like AI... I promise you it's not).

Re: The state of building user interfaces in Rust

#139
post #129

Earlier quoted context omitted.

I would approach anything windows-rs with care, the team is the one responsible for killing C++/CX in name of C++/WinRT, and then leaving it half baked to go play with Rust and windows-rs. Nothing they said on stage at CppCon 2017 came to fruition. You're better off doing the UI in WPF and calling into Rust DLLs.

Makes sense, Microsoft doesn't have the best track record in supporting frameworks. I myself have never worked with C++/CX or C++/WinRT. My Rust journey has been exclusively on POSIX systems, so seeing windows-reactor and getting a UI in a couple of lines is pretty cool. I would never (at least not in its current state) recommend it for production though, as the crate containing reactor isn't even on crates.io. Could…

Easy, that is the beauty of recordings,

You can start by when C++/CX was replaced,

CppCon 2016: “Embracing Standard C++ for the Windows Runtime"

https://www.youtube.com/watch?v=lm4IwfiJ3EU

With the followup talk the year thereafter,

CppCon 2017: “C++/WinRT and the Future of C++ on Windows”

https://www.youtube.com/watch?v=7TdpWB_vRZM

Except the Visual Studio tooling comparable to C++/CX never came to be, using C++/WinRT feels to this day like using ATL with Visual C++ 6.0, except

"This isn't meant as a negative statement. cppwinrt has reached all of its goals and is generally considered complete and largely bug-free (1). Whether WinRT/WinUI/WinAppSDK is the future is debatable. My experience has shown me that the Windows operating system is at its best when you embrace the Windows API as a whole, including Win32/COM/WinRT, and not just the latest shiny wave. You can see this in action with the popularity of projects like win32metadata and windows-rs that support both WinRT and non-WinRT APIs seamlessly."

From https://github.com/microsoft/cppwinrt/issues/1289#issuecomme...

You will notice the open issues are mostly bug fixes.

So who knows what will even happen to windows-rs crate.

Re: The state of building user interfaces in Rust

#140

Rust needs good Qt bindings. None of the existing projects will ever reach Qt. Rust. Cargo. Qt. Go did it with https://github.com/mappu/miqt . Zig did it with https://github.com/rcalixte/libqt6zig . When will Rust do it? The time is now.

Slint is an attempt to build a Qt competitor Although it's built in Rust, it supports a variety of languages + a custom DSL (like QML).

It's more of a QML competitor. I don't think it has anything comparable to QtWidgets.
Post reply on HN