8 ms·

A Proposal for an asynchronous Rust GUI framework

67 points by dntbrsnbl 3y ago

Animats 3y ago
> Here’s one of this year’s dozen new Rust GUIs. Right. On the game engine side, there's the comment that Rust has 50 game engines and 5 games. A new GUI framework might not be what's needed. I'd like to see some of the most used ones get finished. I'm waiting for the six-month WGPU overhaul to finish to unblock the Rend3 overhaul so I can use a newer version of egui. Egui botches layout if there's a line wrap in a scrollable window, for example. Basic stuff like that is broken.
- rcme 3y ago
  I think a bigger issue is that Rust just isn't a good language to write a game engine or a UI in. I wrote a toy game engine in Rust and quickly learned it basically sucks. The entire reason games and UIs exist is to mutate state in weird, complex, and often circular, ways. Rust's borrow checker doesn't lend itself well to this problem.
  - pshc 3y ago
    I think Rust is a great language to write a concurrent stable ECS in, which doesn’t need circular data structures at all. Like bevy.
    - TheRoque 3y ago
      Why is better for this than other languages ? The issue is that it forces you to apply a specific paradigm that may or may not be suited for your use case, and makes it extremely hard to apply other paradigms that you also may need. It's true that there are a few examples of semi-successful games or engines (Veloren, Bevy), but so far it' quite underwhelming... I don't know if the strengths of Rust are even worth it for game dev as a whole
    - winrid 3y ago
      The fact is to ship a game you often need to reach into random parts of the heap to get things done. Can you re-architect your game when you hit this wall to get around it? Yes. Can you try to use hashmaps for everything instead? Yes, to a point. But the person writing their game in C++ will laugh maniacally, do the crazy thing, and ship it.
    - harles 3y ago
      Bevy absolutely allows circular data structures and I’d be surprised if any complex game ships without any - Entity references can easily be circular. Most ECS frameworks are their own memory manager which, sure, prevents running afoul of the borrow checker at compile time but not in spirit. Dangling pointers, null references, and duplicate mutable references all creep into an ECS. They just have new names since it’s all hidden behind Entity rather than a reference or pointer.
      - pshc 3y ago
        In-game structures can of course be circular, logically speaking, by constructing a chain of entities and components that circularly reference each other by entity ID. But you're saying that Bevy has classic pointer-backed reference cycles? That's news to me.
        harles 3y ago
        Its Entity is a pointer by a different name - in that it comes with all the classic problems of pointers. They just happen to live inside Bevy’s memory manager.
        Veliladon 3y ago
        An entity has a generational index though which gets around the whole ABA problem of pointers.
  - jarjoura 3y ago
    Or Rust is just an extremely difficult language to learn when all you really need are shaders and as you say, mutable state. Rust will let you mutate state just like C++, but it's difficult to master in a timely way. So, when your time is better spent on the actual shaders and game logic, you have little patience to learn enough Rust to effectively use it.
    - wiz21c 3y ago
      Exactly. I wanted to code an emulator and said "why not rust". Then I met the BC and pulled hairs for 3 months. After that "honeymoon" with rust, I got to think the b.c. way and my life became just much better. No regret so far. And I even use egui which is very nice to work with. Until I have to share a linked list between different things... But that's another story.
      - WesolyKubeczek 3y ago
        > Then I met the BC and pulled hairs for 3 months. After that "honeymoon" with rust, I got to think the b.c. way and my life became just much better. No regret so far. I’m sorry but it sounds terribly like a textbook example of Stockholm syndrome. I hope one day a language will emerge that has a borrow checker or some other equally effective memory safety measure that doesn’t make the learning curve a fucking smooth upright wall or make its users feel abused and clueless for months.
        wiz21c 3y ago
        I think this will come (and already does) from the libraries. They abstract a lot of the hard-to-get-right details for you. For the rest, I guess the BC comes out of a limitation of the language to express things correctly only. So to remove the BC one would have to build an entirely different language (maybe purely functional ?)
    - flohofwoe 3y ago
      The problem is that you hardly arrive at the correct solution the first time, game development (in the higher game logic layers at least) is an inherently incremental and chaotic process, while Rust heavily prefers careful upfront planning and despises the sort of 'creative chaos' that makes a game work.
  - Klonoar 3y ago
    > I think a bigger issue is that Rust just isn't a good language to write a game engine or a UI in. Here's my hot take of the day, as a Rust dev/fan/proponent who's done a few different GUI projects in the language: it's actually mostly fine, but Rust developers won't just settle for "just make it work". There is true value in a cross-platform common wrapper of native widgets that nobody is really hitting. So many of these GUI attempts are scenarios where it feels like someone stumbled into "how do I build a GUI" and got fascinated by the problem, iterating until they hit a "good enough" point. The problem is that that level of "good enough" isn't actually good enough for a general purpose framework. Arc/Rc the hell out of it, stop trying to get cute with the borrow checker and lifetime handling, and just make it work. 99% of applications that ship today don't need your novel approach to some virtual DOM diffing algorithm, they just need to reliably shit stuff out on a screen in a way that interacts cross-platform well enough.
    - flohofwoe 3y ago
      > Arc/Rc the hell out of it... Ooof, and now were back to what's a fundamental problem in a lot of "traditional" C++ game code bases I've seen (including my own stuff I wrote in the late 90's to early 2010's). Refcounting overhead cannot be ignored when performance matters, and since refcounting usually 'infects' the entire code base, it's impossible to fix once it becomes a performance problem - because then it's too late since it would mean rewriting everything from scratch with a new approach to lifetime management.
      - pjmlp 3y ago
        Yet, not only does the number one C++ engine use refcounting, plenty of commercial engines now have C++ relegated to the core engine, with a scripting language using some form of automatic memory management on top, that drives most of the game code.
        flohofwoe 3y ago
        Despite all the fancy rendering-tech features, Unreal Engine's "core design ideas" are still deeply rooted in the late 90s and early 2000's (just as Unity's, CryEngine/Lumberyard/O3DE's or whatever it is called nowadays - and most of the other big engines that survived from that era). That's also exactly what I wrote above, refcounting is usually entangled so deeply into those engine designs that it can't be fixed without a complete rewrite (Unity attempted it with their new ECS system, but I have no idea how successful that was, AFAIK it still feels like bolted on to the side).
  - dathinab 3y ago
    I would disagree with this. Some points: - UI frameworks and Game Engine tends to be huge when completed to a point where they are an easy choice for anything beyond some fun projects. The _huge_ majority of them have organizations/money backing in some form, through sometimes implicit. So the huge majority of open source versions of them no matter which language they are in will never be competitive. - the state of established UI frameworks is kinda a mess, the divergence between the research world and what is practically used is in most places quite often humongous (e.g. what the blog post describes is conceptually a version of using continuations for GUI libraries and state handling in them, something well established as "a grate idea, if you can make it work nicely with the limitation of widely used programming languages" in computer since since I think 10+ years or so), and it's pretty common that patterns people are used to (e.g. inheritance for code reuse) are actually anti-patterns which kinda somewhat happens to be usable in that case but have serious issues you IMHO often don't notice until using them in larger projects (as in many people working on the software in parallel) where it's then often blamed on other things - due the the mess the state handling in GUIs often ends up in it tends to profit from using a GC and the using borrows only in rust will likely fail. But then given the perf-characteristics and what tends to be a hot paths of GUIs _you really don't need to write borrows only code_, using an Rc/Arc and similar tends to be perfectly fine, i.e. the issue is in my experience more people obsessing over micro optimizations for that context - on the other hand for game engine you often want to avoid GC for the engine/core parts themself (i.e. not dialog script and similar) and in general have a much stricter state handling using stuff like a ECS, there is no reason for rust to not handle that well. Through writing the ECS library might involve usafe code, due to it involving writing fundamental data structures. Most importantly in recent years "memory safety" of C++ has become an increasingly bigger issues for AAA-games, especially for multiplayer games where there is a risk of a hacking the users computer through the game client, and the money spend on combating that issue is non trivial to a point that you probably should avoid most code which conceptually works in C++ but couldn't work in rust due to the borrow checker (assuming you already have a well done ECS library with the right soundly implemented data structures). - similar to writing fundamental data structures, writing a game engine proper is really really hard but seems simple as long as it's only a "toy", rust isn't good at that, sure. But also there is limited value at being good at writing throw away toys which can't be used in any production context IMHO. What does matter is if you can have a nicely usable production ready _maintainable_ game engine in rust, and AFIK yes you can somewhat already have.
- tcfhgj 3y ago
  Perhaps experimentation is a sensible thing in the early days of the Rust ecosystems
- bsder 3y ago
  > On the game engine side, there's the comment that Rust has 50 game engines and 5 games. Bingo. The problem in the Rust ecosystem is that people are writing libraries instead of applications. This is backwards. Until you have a couple of applications written, you have zero idea what to abstract. I'll go further. The Rust GUI ecosystem is fundamentally doomed because they are absolutely insisting that any GUI thing must run on desktop, mobile, and web simultaneously. The abstractions required between those domains are fundamentally incompatible. Desktop apps want "Give me all your cores. Now." Mobile is all about "Please, sir, can I have some battery?" Web is all about "Back in my day all we had was one damn thread so that's all you get and you'll like it." I would personally cheer if we had one good Rust GUI framework for each of those cases.
  - jarjoura 3y ago
    So basically, the same problem any cross-platform framework has.
  - chaosprint 3y ago
    > The problem in the Rust ecosystem is that people are writing libraries instead of applications. I totally second this. Got the same feeling after developing https://glicol.org/ https://glicol.org/
  - cropcirclbureau 3y ago
    My understanding is that most of the new generation of GUI frameworks/application runtime are targeting all platforms. And there's clearly a demand for such feature set if the popularity of Electron says anything. Software businesses no longer want to specialize on specific platforms. What's more, it's provably[0] doable[1] to[2] do[3] so[4]. So, why shouldn't they? [0]: https://avaloniaui.net/ [1]: https:/flutter.dev [2]: https://platform.uno/ [3]: https://unity.com/ [4]: https://www.jetbrains.com/lp/compose-desktop/
    - kristianp 3y ago
      Clickable: [0]: https://avaloniaui.net/ https://avaloniaui.net/ [1]: https://flutter.dev https://flutter.dev [2]: https://platform.uno/ https://platform.uno/ [3]: https://unity.com/ https://unity.com/ [4]: https://www.jetbrains.com/lp/compose-desktop https://www.jetbrains.com/lp/compose-desktop
- zaphirplane 3y ago
  My kind of unscientific impression is Java has a lot of libraries with a relatively few applications. While c# is a lot of applications with few libraries
- yw3410 3y ago
  I've just wanted right click menus and second screens on Wayland for ages. My herd of yaks is only getting higher over time...
wahern 3y ago
A classic use case for coroutines is easily turning a push (callback) interface into a pull (return) interface. I'm sure many people have thought of using coroutines to handle GUI events this way. Certainly I have, and have even written some code along these lines in a macOS app primarily written in Lua (Yue as the GUI toolkit, along with my Lua I/O event library, cqueues, which I used to help tie into some event sources for which Yue lacked support; cqueues was designed to integrate with, rather than displace, other event loops). However, GUI frameworks are a nightmare of criss-crossing events and state, and in practice callbacks are the least of your worries. In other domains callback interfaces often force you to scatter what would otherwise be highly localized logic, but it's the nature of GUI frameworks that your event logic will tend to be short, chunked, and scattered regardless, which is demonstrated by the toy examples. Yes, the async pattern turned event pushes into event pulls syntactically, but that's it--there was no real payoff. I'm sure somebody will eventually go the distance with this approach. I won't dispute that the exercise would be a fun ride.
cropcirclbureau 3y ago
I'm very interested in seeing if using the commonly implemented forms of compiler support for async programming can also be well used for GUI programming. One wishawa[0] is also perusing this approach in Rust but I first came upon this idea from the crank-js[1] authors. It wasn't clear to me why that one never went anywhere. Was it failure with the approach or was React just a good solution in the space? I can say this though, there's something strikingly elegant about those initial samples of using JavaScript generators for components. [0]: https://github.com/wishawa/async_ui https://github.com/wishawa/async_ui [1]: https://github.com/bikeshaving/crank https://github.com/bikeshaving/crank
- yoz 3y ago
  Thanks for reminding me about Crank; it was The Hot New Thing for about a week when it launched. I’m guessing the project lead just couldn’t convert that initial interest into useful contribution. Glad to see he’s still working on it, though.
deleted 3y ago
[deleted]
yidadaa 3y ago
I suggest all GUI developers to familiarize themselves with the cutting-edge frameworks in the frontend community before proposing a new framework. This way, they can avoid the hassle of "reinventing x". Regarding this proposal, it wouldn't hurt to take a look at the implementations of `preact signal` and `vue3 ref` In addition, the overly strict memory management of Rust is a disaster for GUI programming. GUI states are already complex enough, writing GUI in Rust is like adding an enemy called "compiler" to oneself.

67 points by dntbrsnbl 3y ago

> Here’s one of this year’s dozen new Rust GUIs. Right. On the game engine side, there's the comment that Rust has 50 game engines and 5 games. A new GUI framework might not be what's needed. I'd like to see some of the most used ones get finished. I'm waiting for the six-month WGPU overhaul to finish to unblock the Rend3 overhaul so I can use a newer version of egui. Egui botches layout if there's a line wrap in a scrollable window, for example. Basic stuff like that is broken.

rcme 3y ago
I think a bigger issue is that Rust just isn't a good language to write a game engine or a UI in. I wrote a toy game engine in Rust and quickly learned it basically sucks. The entire reason games and UIs exist is to mutate state in weird, complex, and often circular, ways. Rust's borrow checker doesn't lend itself well to this problem.
- pshc 3y ago
  I think Rust is a great language to write a concurrent stable ECS in, which doesn’t need circular data structures at all. Like bevy.
  - TheRoque 3y ago
    Why is better for this than other languages ? The issue is that it forces you to apply a specific paradigm that may or may not be suited for your use case, and makes it extremely hard to apply other paradigms that you also may need. It's true that there are a few examples of semi-successful games or engines (Veloren, Bevy), but so far it' quite underwhelming... I don't know if the strengths of Rust are even worth it for game dev as a whole
  - winrid 3y ago
    The fact is to ship a game you often need to reach into random parts of the heap to get things done. Can you re-architect your game when you hit this wall to get around it? Yes. Can you try to use hashmaps for everything instead? Yes, to a point. But the person writing their game in C++ will laugh maniacally, do the crazy thing, and ship it.
  - harles 3y ago
    Bevy absolutely allows circular data structures and I’d be surprised if any complex game ships without any - Entity references can easily be circular. Most ECS frameworks are their own memory manager which, sure, prevents running afoul of the borrow checker at compile time but not in spirit. Dangling pointers, null references, and duplicate mutable references all creep into an ECS. They just have new names since it’s all hidden behind Entity rather than a reference or pointer.
    - pshc 3y ago
      In-game structures can of course be circular, logically speaking, by constructing a chain of entities and components that circularly reference each other by entity ID. But you're saying that Bevy has classic pointer-backed reference cycles? That's news to me.
      - harles 3y ago
        Its Entity is a pointer by a different name - in that it comes with all the classic problems of pointers. They just happen to live inside Bevy’s memory manager.
        Veliladon 3y ago
        An entity has a generational index though which gets around the whole ABA problem of pointers.
- jarjoura 3y ago
  Or Rust is just an extremely difficult language to learn when all you really need are shaders and as you say, mutable state. Rust will let you mutate state just like C++, but it's difficult to master in a timely way. So, when your time is better spent on the actual shaders and game logic, you have little patience to learn enough Rust to effectively use it.
  - wiz21c 3y ago
    Exactly. I wanted to code an emulator and said "why not rust". Then I met the BC and pulled hairs for 3 months. After that "honeymoon" with rust, I got to think the b.c. way and my life became just much better. No regret so far. And I even use egui which is very nice to work with. Until I have to share a linked list between different things... But that's another story.
    - WesolyKubeczek 3y ago
      > Then I met the BC and pulled hairs for 3 months. After that "honeymoon" with rust, I got to think the b.c. way and my life became just much better. No regret so far. I’m sorry but it sounds terribly like a textbook example of Stockholm syndrome. I hope one day a language will emerge that has a borrow checker or some other equally effective memory safety measure that doesn’t make the learning curve a fucking smooth upright wall or make its users feel abused and clueless for months.
      - wiz21c 3y ago
        I think this will come (and already does) from the libraries. They abstract a lot of the hard-to-get-right details for you. For the rest, I guess the BC comes out of a limitation of the language to express things correctly only. So to remove the BC one would have to build an entirely different language (maybe purely functional ?)
  - flohofwoe 3y ago
    The problem is that you hardly arrive at the correct solution the first time, game development (in the higher game logic layers at least) is an inherently incremental and chaotic process, while Rust heavily prefers careful upfront planning and despises the sort of 'creative chaos' that makes a game work.
- Klonoar 3y ago
  > I think a bigger issue is that Rust just isn't a good language to write a game engine or a UI in. Here's my hot take of the day, as a Rust dev/fan/proponent who's done a few different GUI projects in the language: it's actually mostly fine, but Rust developers won't just settle for "just make it work". There is true value in a cross-platform common wrapper of native widgets that nobody is really hitting. So many of these GUI attempts are scenarios where it feels like someone stumbled into "how do I build a GUI" and got fascinated by the problem, iterating until they hit a "good enough" point. The problem is that that level of "good enough" isn't actually good enough for a general purpose framework. Arc/Rc the hell out of it, stop trying to get cute with the borrow checker and lifetime handling, and just make it work. 99% of applications that ship today don't need your novel approach to some virtual DOM diffing algorithm, they just need to reliably shit stuff out on a screen in a way that interacts cross-platform well enough.
  - flohofwoe 3y ago
    > Arc/Rc the hell out of it... Ooof, and now were back to what's a fundamental problem in a lot of "traditional" C++ game code bases I've seen (including my own stuff I wrote in the late 90's to early 2010's). Refcounting overhead cannot be ignored when performance matters, and since refcounting usually 'infects' the entire code base, it's impossible to fix once it becomes a performance problem - because then it's too late since it would mean rewriting everything from scratch with a new approach to lifetime management.
    - pjmlp 3y ago
      Yet, not only does the number one C++ engine use refcounting, plenty of commercial engines now have C++ relegated to the core engine, with a scripting language using some form of automatic memory management on top, that drives most of the game code.
      - flohofwoe 3y ago
        Despite all the fancy rendering-tech features, Unreal Engine's "core design ideas" are still deeply rooted in the late 90s and early 2000's (just as Unity's, CryEngine/Lumberyard/O3DE's or whatever it is called nowadays - and most of the other big engines that survived from that era). That's also exactly what I wrote above, refcounting is usually entangled so deeply into those engine designs that it can't be fixed without a complete rewrite (Unity attempted it with their new ECS system, but I have no idea how successful that was, AFAIK it still feels like bolted on to the side).
- dathinab 3y ago
  I would disagree with this. Some points: - UI frameworks and Game Engine tends to be huge when completed to a point where they are an easy choice for anything beyond some fun projects. The _huge_ majority of them have organizations/money backing in some form, through sometimes implicit. So the huge majority of open source versions of them no matter which language they are in will never be competitive. - the state of established UI frameworks is kinda a mess, the divergence between the research world and what is practically used is in most places quite often humongous (e.g. what the blog post describes is conceptually a version of using continuations for GUI libraries and state handling in them, something well established as "a grate idea, if you can make it work nicely with the limitation of widely used programming languages" in computer since since I think 10+ years or so), and it's pretty common that patterns people are used to (e.g. inheritance for code reuse) are actually anti-patterns which kinda somewhat happens to be usable in that case but have serious issues you IMHO often don't notice until using them in larger projects (as in many people working on the software in parallel) where it's then often blamed on other things - due the the mess the state handling in GUIs often ends up in it tends to profit from using a GC and the using borrows only in rust will likely fail. But then given the perf-characteristics and what tends to be a hot paths of GUIs _you really don't need to write borrows only code_, using an Rc/Arc and similar tends to be perfectly fine, i.e. the issue is in my experience more people obsessing over micro optimizations for that context - on the other hand for game engine you often want to avoid GC for the engine/core parts themself (i.e. not dialog script and similar) and in general have a much stricter state handling using stuff like a ECS, there is no reason for rust to not handle that well. Through writing the ECS library might involve usafe code, due to it involving writing fundamental data structures. Most importantly in recent years "memory safety" of C++ has become an increasingly bigger issues for AAA-games, especially for multiplayer games where there is a risk of a hacking the users computer through the game client, and the money spend on combating that issue is non trivial to a point that you probably should avoid most code which conceptually works in C++ but couldn't work in rust due to the borrow checker (assuming you already have a well done ECS library with the right soundly implemented data structures). - similar to writing fundamental data structures, writing a game engine proper is really really hard but seems simple as long as it's only a "toy", rust isn't good at that, sure. But also there is limited value at being good at writing throw away toys which can't be used in any production context IMHO. What does matter is if you can have a nicely usable production ready _maintainable_ game engine in rust, and AFIK yes you can somewhat already have.
tcfhgj 3y ago
Perhaps experimentation is a sensible thing in the early days of the Rust ecosystems
bsder 3y ago
> On the game engine side, there's the comment that Rust has 50 game engines and 5 games. Bingo. The problem in the Rust ecosystem is that people are writing libraries instead of applications. This is backwards. Until you have a couple of applications written, you have zero idea what to abstract. I'll go further. The Rust GUI ecosystem is fundamentally doomed because they are absolutely insisting that any GUI thing must run on desktop, mobile, and web simultaneously. The abstractions required between those domains are fundamentally incompatible. Desktop apps want "Give me all your cores. Now." Mobile is all about "Please, sir, can I have some battery?" Web is all about "Back in my day all we had was one damn thread so that's all you get and you'll like it." I would personally cheer if we had one good Rust GUI framework for each of those cases.
- jarjoura 3y ago
  So basically, the same problem any cross-platform framework has.
- chaosprint 3y ago
  > The problem in the Rust ecosystem is that people are writing libraries instead of applications. I totally second this. Got the same feeling after developing https://glicol.org/ https://glicol.org/
- cropcirclbureau 3y ago
  My understanding is that most of the new generation of GUI frameworks/application runtime are targeting all platforms. And there's clearly a demand for such feature set if the popularity of Electron says anything. Software businesses no longer want to specialize on specific platforms. What's more, it's provably[0] doable[1] to[2] do[3] so[4]. So, why shouldn't they? [0]: https://avaloniaui.net/ [1]: https:/flutter.dev [2]: https://platform.uno/ [3]: https://unity.com/ [4]: https://www.jetbrains.com/lp/compose-desktop/
  - kristianp 3y ago
    Clickable: [0]: https://avaloniaui.net/ https://avaloniaui.net/ [1]: https://flutter.dev https://flutter.dev [2]: https://platform.uno/ https://platform.uno/ [3]: https://unity.com/ https://unity.com/ [4]: https://www.jetbrains.com/lp/compose-desktop https://www.jetbrains.com/lp/compose-desktop
zaphirplane 3y ago
My kind of unscientific impression is Java has a lot of libraries with a relatively few applications. While c# is a lot of applications with few libraries
yw3410 3y ago
I've just wanted right click menus and second screens on Wayland for ages. My herd of yaks is only getting higher over time...

wahern 3y ago

A classic use case for coroutines is easily turning a push (callback) interface into a pull (return) interface. I'm sure many people have thought of using coroutines to handle GUI events this way. Certainly I have, and have even written some code along these lines in a macOS app primarily written in Lua (Yue as the GUI toolkit, along with my Lua I/O event library, cqueues, which I used to help tie into some event sources for which Yue lacked support; cqueues was designed to integrate with, rather than displace, other event loops). However, GUI frameworks are a nightmare of criss-crossing events and state, and in practice callbacks are the least of your worries. In other domains callback interfaces often force you to scatter what would otherwise be highly localized logic, but it's the nature of GUI frameworks that your event logic will tend to be short, chunked, and scattered regardless, which is demonstrated by the toy examples. Yes, the async pattern turned event pushes into event pulls syntactically, but that's it--there was no real payoff. I'm sure somebody will eventually go the distance with this approach. I won't dispute that the exercise would be a fun ride.

cropcirclbureau 3y ago

I'm very interested in seeing if using the commonly implemented forms of compiler support for async programming can also be well used for GUI programming. One wishawa[0] is also perusing this approach in Rust but I first came upon this idea from the crank-js[1] authors. It wasn't clear to me why that one never went anywhere. Was it failure with the approach or was React just a good solution in the space? I can say this though, there's something strikingly elegant about those initial samples of using JavaScript generators for components. [0]: https://github.com/wishawa/async_ui https://github.com/wishawa/async_ui [1]: https://github.com/bikeshaving/crank https://github.com/bikeshaving/crank

yoz 3y ago
Thanks for reminding me about Crank; it was The Hot New Thing for about a week when it launched. I’m guessing the project lead just couldn’t convert that initial interest into useful contribution. Glad to see he’s still working on it, though.

deleted 3y ago

[deleted]

yidadaa 3y ago

I suggest all GUI developers to familiarize themselves with the cutting-edge frameworks in the frontend community before proposing a new framework. This way, they can avoid the hassle of "reinventing x". Regarding this proposal, it wouldn't hurt to take a look at the implementations of `preact signal` and `vue3 ref` In addition, the overly strict memory management of Rust is a disaster for GUI programming. GUI states are already complex enough, writing GUI in Rust is like adding an enemy called "compiler" to oneself.