Because, IMHO, a lot if not every of the GUI frameworks have been born by necessity and has a lot of cruft around that requires type magic incompatible with a strict language like Rust.
GUI toolkits are often really old (more than 20 years old at least) and have been either hastily hacked in C (often in C89, like Win32 and GTK+, which is famous to abuse refcounting and C macros and is a prime example of what I was mentioning above as a poorly designed library), or have been designed in C++ before C++11, so they largely depend on nasty hacks and practises that are considered obsolete in modern C++ (like Qt).
Other GUI toolkits are designed around modern garbage collected languages (see WinForms, WPF, Swing, ...) so they're not really usable from non-managed languages.
Cocoa is in a weird spot, being written in a pretty-much duck-typed language like Objective-C.
My point is that IMHO it's not Rust itself that's not suited for GUIs, but it's the GUI toolkits that have often aged very badly and are out of touch with modern software development. The ugliness of developing UIs with the old frameworks is I think one of the main reasons why the web has taken over, and why others such as Qt have largely moved to a declarative approach with things like QtQuick (i.e. "almost JS") or Apple's SwiftUI.
It's all about keeping development sane, something Microsoft has IMHO canned several times by trying fix the mess they made with Win32, only by making it worse creating a dozen of competing, almost incompatible toolkits. The fact that the newest of them, written since its inception in modern C++ (C++/WinRT) has a nice to use Rust alternative (Rust/WinRT) shows that the problem wasn't the language all along.
Given how C++/WinRT currently represents a huge step back from C++/CX tooling capabilities, and Rust/WinRT is still doing baby steps to match C++/WinRT, I rather wait and see.
I bet just like it happened with C++/CX and C++/WinRT, Microsoft will be the major user, while everyone else outside Redmond will use .NET instead.
Ralf Levien has already posted several blog post how even writing a Rust specific UI toolkit from scratch is not as straightforward as he thought it would be.
The Web has taken over because many junior devs don't know any better, and I am really happy that WebAssembly + WebGL is already bringing Flash like tooling back to the Web.
While I understand the problem, sadly that has never been something that I was involved with more than 30 years coding. I really never saw it as part of any acceptance criteria, other than a couple of government sites.
On the positive note, eventually such frameworks might offer the necessary support.
I don't think that's an accurate summary of my blog post. I've never thought building GUI in Rust would be straightforward. I'll try for a tl;dr summary, as it might be useful to this thread:
Building a GUI toolkit is a huge task, with many subtasks that are themselves serious efforts (2D drawing, text, reactive architecture, etc). The Druid project has been engaging these problems and coming up with pretty good solutions. Trying to rush the effort (for example, by trying to lash together existing modules) won't be helpful. In coming months, the project will continue focus on trying to deliver one application, the Runebender font editor, rather than trying to be a general purpose GUI toolkit product. We've been growing a really good community and there are lots of opportunities to learn more about GUI technology and help the project along.
I'm a bit biased, perhaps, but I'm extremely optimistic about the prospects for GUI in Rust. But if people are impatient and hoping for a solution they can deploy right now, no, it's not there yet.
Honestly I cannot see how to achieve something like Swift UI or Jetpack Composer, without littering Rust code with explicit reference counting.
I am also considering having visual editor in real time, and the ability to have a widget ecosystem that one just drops into the tool palette and can bind its connections in any way, possibly not considered by the widget author.
I am also looking forward to how Microsoft will eventually sort out Rust/WinRT, which has an easier job, given that COM is by definition RC based, but there is the whole usability story when putting it face to face with what .NET and C++/CX offer out of the box (C++/WinRT after 4 years in development is still catching up with VS tooling for C++/CX from 2012).
No worries, clear communication around this area is difficult.
SwiftUI and Jetpack Compose are completely different beasts, though they might look similar from the outside. SwiftUI relies heavily on observable objects and basically a shared-mutable-state architecture. I believe that adapting it into Rust would be a nightmare.
Jetpack Compose, on the other hand, lets the app logic build the UI with method calls that resemble immediate mode GUI (though there are of course important differences, as it is building a retained widget tree). These updates are mediated through a mutable context object ("Composer" in the Jetpack Compose world), which adapts quite nicely into the Rust world. In particular, it does not depend on shared mutable references.
I strongly believe that it is possible to express UI in Rust quite naturally and expressively. I've written a fair amount about this recently and have provided evidence in the form of the existing Druid work and the Crochet research prototype, which represents an evolution of its reactive architecture to better support dynamic reconfiguration (a current weak spot in Druid). Of course, we won't know for sure til we get there, but in the meantime it would be nice if the naysayers at least made informed criticism.
> I am also considering having visual editor in real time, and the ability to have a widget ecosystem that one just drops into the tool palette and can bind its connections in any way, possibly not considered by the widget author.
These things trade away some runtime efficiency for developer productivity. And for many applications, that's the right trade. That's not really what Rust is about, though. I think .NET will remain a better choice for that kind of application. I just hope .NET gets a good full-AOT solution (including whole-program optimization) for desktop apps, so users don't have to pay excessively for that tradeoff.
> My point is that IMHO it's not Rust itself that's not suited for GUIs, but it's the GUI toolkits that have often aged very badly and are out of touch with modern software development.
The post was about writing a Rust wrapper for Wayland -- I thought Wayland was supposed to be a relatively new/modern framework.
It seems like windowing toolkits in general might present some difficult scenarios for Rust, regardless of age.
The post was about writing a wrapper for wlroots, a Wayland library designed to simplify writing Wayland compositors upon which Sway is made, not Wayland itself. There is a nice reimplementation/wrap of Wayland C libraries, and it's wayland-rs.
Developing UIs with toolkits like Delphi's VCL was much faster than web development - as long as your UI was form-oriented and you had a pre-made, configurable control for everything you wanted to add.
But as soon as you get down to needing to do your own drawing, a complexity cliff rises up.
The web is the other way around. With sufficient styling you can get a UI which matches your vision without having to write a lot of imperative code, but if you want to put a simple application together quickly, there's a real risk of analysis paralysis owing to how much control you have.
GUI toolkits are often really old (more than 20 years old at least) and have been either hastily hacked in C (often in C89, like Win32 and GTK+, which is famous to abuse refcounting and C macros and is a prime example of what I was mentioning above as a poorly designed library), or have been designed in C++ before C++11, so they largely depend on nasty hacks and practises that are considered obsolete in modern C++ (like Qt).
Other GUI toolkits are designed around modern garbage collected languages (see WinForms, WPF, Swing, ...) so they're not really usable from non-managed languages. Cocoa is in a weird spot, being written in a pretty-much duck-typed language like Objective-C.
My point is that IMHO it's not Rust itself that's not suited for GUIs, but it's the GUI toolkits that have often aged very badly and are out of touch with modern software development. The ugliness of developing UIs with the old frameworks is I think one of the main reasons why the web has taken over, and why others such as Qt have largely moved to a declarative approach with things like QtQuick (i.e. "almost JS") or Apple's SwiftUI.
It's all about keeping development sane, something Microsoft has IMHO canned several times by trying fix the mess they made with Win32, only by making it worse creating a dozen of competing, almost incompatible toolkits. The fact that the newest of them, written since its inception in modern C++ (C++/WinRT) has a nice to use Rust alternative (Rust/WinRT) shows that the problem wasn't the language all along.