4 ms·

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

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.

pjmlp 6y ago
Sorry if I misrepresented your work. 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).
- raphlinus 6y ago
  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.
- mwcampbell 6y ago
  > 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.
  - pjmlp 6y ago
    I can get those tools for C++, Delphi, Swift, Ada as well.

pjmlp 6y ago

Sorry if I misrepresented your work. 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).

raphlinus 6y ago
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.
mwcampbell 6y ago
> 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.
- pjmlp 6y ago
  I can get those tools for C++, Delphi, Swift, Ada as well.