Comment by raphlinus
1 day ago
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 the reason why it's so hard is that the requirements for different apps vary widely; I think we are spoiled by the relative cohesion
* The infrastructure is in disrepair
A UI is built on top of lots of infrastructural pieces, obviously including graphics and compositing, but also text, accessibility, input handling, and many other things. When you look at support for those layers across platforms, it's like picking up a rock and seeing the bugs crawl. Take compositing: Windows and Mac have excellent compositors, Android and Linux much less so. But even there the features don't line up, Mac doesn't support incremental present (they don't really need to, considering how beefy their chips are, but it's really important on low end Android).
So a lot of the challenge is working around the brokenness across the various platforms. But, good news, there is really excellent progress on all these fronts. We now have solid text layout in Rust, a clear winner on accessibility, and even poor winit is making slow, steady progress.
I'd also like to say, by contrast the web has really been investing in infrastructure, and hides much of the lower level pain from developers. I think that's a major reason Electron is winning so much.
* The computer science is not quite done
We're still in an exploratory phase to figure out the best patterns for writing Rust UI. At the core of that is reactivity, which is at heart incremental computation. Most systems are converging on a hybrid of something generally React like (coarser grain reactivity) with fine-grained signals. I'd like to think there is a Right Answer here and that it's possible to find it.
This feels to me a bit like async. The foundations for async Rust were laid 10 years ago, but it still doesn't feel fully baked. I've seen some exciting recent work about improving the confusing Pin mechanism with something more principled. We'll get there, but it takes time.
I make three predictions:
* Rust UI will continue to improve, as the infrastructure is built out, we try more things, and projects mature. But not quickly.
* If we thought we had a lot of Rust UI projects before, wait til we see what AI wreaks. I predict we'll see dozens of vibe coded Rust UI toolkits.
* In the longer term, we're going to have Rust UI anyway, as browsers are increasingly going to be rewritten in Rust, and apps will be built on Web technology. And that's not just Electron, the modular browser approach pioneered by Blitz is also promising.
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.