A Proposal for an asynchronous Rust GUI framework
notgull.github.io
A Proposal for an asynchronous Rust GUI framework
1–10 of 59 posts
Re: A Proposal for an asynchronous Rust GUI framework
#2> 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.
Re: A Proposal for an asynchronous Rust GUI framework
#3> 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…
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.
Re: A Proposal for an asynchronous Rust GUI framework
#4> 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…
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.
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.
Re: A Proposal for an asynchronous Rust GUI framework
#5Earlier quoted context omitted.
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.
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.
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
Re: A Proposal for an asynchronous Rust GUI framework
#6Earlier quoted context omitted.
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.
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.
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.
Re: A Proposal for an asynchronous Rust GUI framework
#7> 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…
Perhaps experimentation is a sensible thing in the early days of the Rust ecosystems
Re: A Proposal for an asynchronous Rust GUI framework
#8A 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.
Re: A Proposal for an asynchronous Rust GUI framework
#9> 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…
> 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.
Re: A Proposal for an asynchronous Rust GUI framework
#10I'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.