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

41–50 of 59 posts

Re: A Proposal for an asynchronous Rust GUI framework

#41

Post by rewmie »

Klonoar wrote: post #31
kaba0 wrote: post #29

Earlier quoted context omitted.

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

There are a litany of benefits to Rust that include, but are not limited to: - Cargo and the general ecosystem - The relative ease of integrating with just about any other system - The ability to just build a binary rather than dealing with bundling interpreted languages (like with general Python/Ruby/JS/etc) See my other comment in this thread for why I consider that "higher overhead" to be meaningless for general a…

> There are a litany of benefits to Rust that include, but are not limited to

Other than Cargo, none of the advantages you mentioned are actually advantages, and are just basic features that are shared by multiple programming languages for decades.

If it's hard to justify Rust's use, why insist it's a decent tech stack for this sort of applications in spite of all of the evidence to the contrary?

Re: A Proposal for an asynchronous Rust GUI framework

#42

Post by flohofwoe »

Klonoar wrote: post #37
flohofwoe wrote: post #33

Earlier quoted context omitted.

If you treat every UI widget as its own refcounted object (or even multiple), maybe even uniquely heap-allocated, arranged in deep hierarchies, and share references to those objects within and outside the UI code, then the situation isn't much different from a typical OOP game code base (just replace "UI widget" with "game object") The most important 'technical quality' of both application types is that user interact…

> but it will become one with tens- or hundreds-of-thousands of refcounted objects which are frequently created and destroyed (and with a naive approach those numbers are easily in reach as soon as table views come into play) Look, I'm sorry but it's just bananas to throw around "hundreds of thousands of refcounted objects" when I've already bluntly pointed out that I'm discussing general application building. Joe Sc…

> Joe Schmoe wanting to put together an email client ... and move on with their life.

Tbh, for that type of problem a smart Joe Schmoe wouldn't pick a tech stack like Rust in the first place, and instead just write a simple web app (because implementation details aside, the next problem is how to distribute the damn thing without "sideloading" or "potentially harmful download" warnings popping up all over the place).

Re: A Proposal for an asynchronous Rust GUI framework

#43

Post by dathinab »

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.

it sounds like rust is harder to learn then shaders which is kinda funny

while the base concepts of shaders might be easy, IMHO are far far harder to use correctly and maintainable then rust

anyway I agree that for a lot of use cases you want a ready to go game engine where most of the code you write is in some form of scripting engine on top and only the perf relevant code is in whatever native language you use

through many people today start programming without knowing C++ and I would argue rust is much easier to learn then C++ with that one small problem that C++ can give you easily an illusion of having a proper understanding of it while still missing very essential parts which can not only lead to failing but also RCE security vulnerable code

Re: A Proposal for an asynchronous Rust GUI framework

#44

Post by Klonoar »

rewmie wrote: post #41
Klonoar wrote: post #31

Earlier quoted context omitted.

There are a litany of benefits to Rust that include, but are not limited to: - Cargo and the general ecosystem - The relative ease of integrating with just about any other system - The ability to just build a binary rather than dealing with bundling interpreted languages (like with general Python/Ruby/JS/etc) See my other comment in this thread for why I consider that "higher overhead" to be meaningless for general a…

> There are a litany of benefits to Rust that include, but are not limited to Other than Cargo, none of the advantages you mentioned are actually advantages, and are just basic features that are shared by multiple programming languages for decades . If it's hard to justify Rust's use, why insist it's a decent tech stack for this sort of applications in spite of all of the evidence to the contrary?

I thought I made it clear - but apparently I should have been far more blunt - that I don't particularly value going in to a comment chain regarding "justify Rust's use for $X". I say this to point out that you're trying to imply:

> If it's hard to justify Rust's use

I don't consider it hard, I'm just not spending time on it because it's not worth it to me. If I felt it was worth it, I could discuss language features or so on (error handling, functional programming idioms, etc). It's covered fine elsewhere. ;P

> Why insist it's a decent tech stack for this sort of applications in spite of all of the evidence to the contrary?

This entire thread is due to my not buying the "evidence" that it's hard.

Go write in whatever language you want. I want to write in Rust, and I want a functioning GUI framework and I think people are overthinking it. shrug

Re: A Proposal for an asynchronous Rust GUI framework

#45

Post by Klonoar »

flohofwoe wrote: post #42
Klonoar wrote: post #37

Earlier quoted context omitted.

> but it will become one with tens- or hundreds-of-thousands of refcounted objects which are frequently created and destroyed (and with a naive approach those numbers are easily in reach as soon as table views come into play) Look, I'm sorry but it's just bananas to throw around "hundreds of thousands of refcounted objects" when I've already bluntly pointed out that I'm discussing general application building. Joe Sc…

> Joe Schmoe wanting to put together an email client ... and move on with their life. Tbh, for that type of problem a smart Joe Schmoe wouldn't pick a tech stack like Rust in the first place, and instead just write a simple web app (because implementation details aside, the next problem is how to distribute the damn thing without "sideloading" or "potentially harmful download" warnings popping up all over the place).

You're focusing on the "email" part when the point is the widget type itself, which signals to me we've reached some form of an end to this I guess.

(And that's not even going in to why one might not want to deal with the web)

Re: A Proposal for an asynchronous Rust GUI framework

#46

Post by WesolyKubeczek »

wiz21c wrote: post #20
jarjoura wrote: post #11

Earlier quoted context omitted.

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.

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

Re: A Proposal for an asynchronous Rust GUI framework

#47

Post by yoz »

cropcirclbureau wrote: post #10

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

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.

Re: A Proposal for an asynchronous Rust GUI framework

#48

Post by yidadaa »

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.

Re: A Proposal for an asynchronous Rust GUI framework

#49

Post by Hamcha »

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 company's root are of a gamedev (Over the Edge Entertainment) and recycled their in-house engine as a product. Godot Engine has similar roots (look up OKAM Studio)

Re: A Proposal for an asynchronous Rust GUI framework

#50

Post by zaphirplane »

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…

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

Post reply on HN