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

21–30 of 59 posts

Re: A Proposal for an asynchronous Rust GUI framework

#21

Post by troupo »

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…

> most of the new generation of GUI frameworks/application runtime are targeting all platforms

And they all fail miserably in innumerable ways that make you reach for OS-specific solutions if those frameworks allow that.

Just the simple fact that mist mobile is touch-oriented small screens with imprecise controls, and desktop is mouse-and-keybord-oriented with big screens and precise controls make the two largely incompatible.

Re: A Proposal for an asynchronous Rust GUI framework

#22

Post by raincole »

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 most popular game engine ever is developed by a company that doesn't make games.

Re: A Proposal for an asynchronous Rust GUI framework

#23

Post by flohofwoe »

Klonoar wrote: post #16
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 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 o…

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

Re: A Proposal for an asynchronous Rust GUI framework

#24

Post by pjmlp »

flohofwoe wrote: post #23
Klonoar wrote: post #16

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

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

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.

Re: A Proposal for an asynchronous Rust GUI framework

#25

Post by flohofwoe »

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.

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.

Re: A Proposal for an asynchronous Rust GUI framework

#26

Post by lelanthran »

raincole wrote: post #22
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…

The most popular game engine ever is developed by a company that doesn't make games.

> The most popular game engine ever is developed by a company that doesn't make games.

So? They have the feedback from thousands of games and game developers so they focus on alleviating the pain points.

If you don't have feedback, you may as well not bother.

Ship your Rust game, then you know what the pain points are. Until you ship, you're guessing.

Re: A Proposal for an asynchronous Rust GUI framework

#27

Post by pjmlp »

raincole wrote: post #22
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…

The most popular game engine ever is developed by a company that doesn't make games.

Mostly because it is the only available option if one wants C# instead of C++ with great tooling, asset store and official backing from platform owners.

None of Rust libraries is even close of getting there, even the studios that apparently support Rust, are shipping on Unreal.

Re: A Proposal for an asynchronous Rust GUI framework

#28

Post by flohofwoe »

pjmlp wrote: post #24
flohofwoe wrote: post #23

Earlier quoted context omitted.

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

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.

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

Re: A Proposal for an asynchronous Rust GUI framework

#29

Post by kaba0 »

Klonoar wrote: post #16
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 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 o…

At that point, why Rust? Like, ARC has a much higher overhead than a good GC.

Re: A Proposal for an asynchronous Rust GUI framework

#30

Post by Klonoar »

flohofwoe wrote: post #23
Klonoar wrote: post #16

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

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

> what's a fundamental problem in a lot of "traditional" C++ game code bases

I'll be more clear that I consider the needs of games and the needs of general apps to be very different, and I am particularly discussing the latter and not the former.

> Refcounting overhead cannot be ignored when performance matters,

People throw around the meme of "performance matters" in the GUI space when we've had mostly working solutions for the 99% percentile of applications for decades now. You're going to throw pretty much all your work to a background thread and send some updates over, or you're going to draw to a canvas of sorts that will likely bypass things altogether.

Refcounting is fine for a GUI framework and I am arguing that there is more value in something that ships and works today than waiting around for the next research project GUI framework approach to take off.

Note that I am not saying there's no value in the exploration of a GUI framework that feels "right" for Rust, I'm just saying that the insistence on that being the only goal is odd and ultimately holding the community back.

Post reply on HN