Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Proposal for an asynchronous Rust GUI framework

notgull.github.io

Post reply on HN
Print view View original

11–20 of 59 posts

Re: A Proposal for an asynchronous Rust GUI framework

#11

Post by jarjoura »

rcme wrote: post #3
Animats wrote: post #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…

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.

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.

Re: A Proposal for an asynchronous Rust GUI framework

#12

Post by harles »

pshc wrote: post #4
rcme wrote: post #3

Earlier 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.

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.

Re: A Proposal for an asynchronous Rust GUI framework

#13

Post by jarjoura »

bsder wrote: post #9
Animats wrote: post #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…

> 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 m…

So basically, the same problem any cross-platform framework has.

Re: A Proposal for an asynchronous Rust GUI framework

#14

Post by chaosprint »

bsder wrote: post #9
Animats wrote: post #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…

> 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 m…

> 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/

Re: A Proposal for an asynchronous Rust GUI framework

#15

Post by cropcirclbureau »

bsder wrote: post #9
Animats wrote: post #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…

> 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 m…

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/

Re: A Proposal for an asynchronous Rust GUI framework

#16

Post by Klonoar »

rcme wrote: post #3
Animats wrote: post #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…

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 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.

Re: A Proposal for an asynchronous Rust GUI framework

#17

Post by kristianp »

cropcirclbureau wrote: post #15
bsder wrote: post #9

Earlier quoted context omitted.

> 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 m…

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.de…

Clickable:

[0]: https://avaloniaui.net/

[1]: https://flutter.dev

[2]: https://platform.uno/

[3]: https://unity.com/

[4]: https://www.jetbrains.com/lp/compose-desktop

Re: A Proposal for an asynchronous Rust GUI framework

#18

Post by darthrupert »

bsder wrote: post #9
Animats wrote: post #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…

> 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 m…

Rust community seems altruistic, so perhaps they're just making the mistake of trying to fix everybody's problems instead of just focusing on the simple immediate one: making money.

I could suggest that this is why capitalism works as a tool to improve society, but perhaps that extrapolates a bit too wildly.

Re: A Proposal for an asynchronous Rust GUI framework

#19

Post by Animats »

bsder wrote: post #9
Animats wrote: post #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…

> 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 m…

> 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."

As a Rend3/Wgpu user, I'm very aware of that.

Web is very "you only have one thread and you will use async."

Re: A Proposal for an asynchronous Rust GUI framework

#20

Post by wiz21c »

jarjoura wrote: post #11
rcme wrote: post #3

Earlier 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.

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.

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.

Post reply on HN