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

51–59 of 59 posts

Re: A Proposal for an asynchronous Rust GUI framework

#51

Post by bryanlarsen »

kaba0 wrote: post #29
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…

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

Rust is often the best language for the meat of your program; it's nice to use it for the gravy too.

Many, if not most, programs are not primarily UI's. They exist to control something, calculate something, transform something, et cetera.

All of these need a human interface. Perhaps a command line and a config file is sufficient, but often an interactive UI helps.

You could create an API to your rust program and then write the UI in something else, but there are huge benefits in writing both in the same language.

Re: A Proposal for an asynchronous Rust GUI framework

#52

Post by pshc »

harles wrote: post #12
pshc wrote: post #4

Earlier quoted context omitted.

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…

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.

Re: A Proposal for an asynchronous Rust GUI framework

#53

Post by yw3410 »

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've just wanted right click menus and second screens on Wayland for ages.

My herd of yaks is only getting higher over time...

Re: A Proposal for an asynchronous Rust GUI framework

#54

Post by harles »

pshc wrote: post #52
harles wrote: post #12

Earlier quoted context omitted.

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…

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.

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.

Re: A Proposal for an asynchronous Rust GUI framework

#55

Post by Veliladon »

harles wrote: post #54
pshc wrote: post #52

Earlier quoted context omitted.

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.

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.

An entity has a generational index though which gets around the whole ABA problem of pointers.

Re: A Proposal for an asynchronous Rust GUI framework

#56

Post by rewmie »

Klonoar wrote: post #44
rewmie wrote: post #41

Earlier quoted context omitted.

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

Your empty claims hold no water. You stat you don't consider it hard to justify Rust's use, but you still failed to provide any suport, let alone a coherent argument, justifying it's use.

I get fanboys want to support their pet tech stack no matter what and in spite of all evidence, but hand waving over the problem doesn't lead to progress. It just pushes an irrational belief that helps no one, and just showcases a need to lose touch with reality.

Re: A Proposal for an asynchronous Rust GUI framework

#57

Post by Animats »

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

The pattern I keep needing is single ownership with back pointers. That can be done with Rc and Weak, which pushes the checking to run time. I think it might be possible to do this statically with some extensions to the borrow checker. It's not keeping the forward and back links consistent that is hard. It's making sure that all code sections either have read access to owner and owned, or write access to owner or owned. That's a static analysis kind of problem.

Re: A Proposal for an asynchronous Rust GUI framework

#58

Post by wiz21c »

WesolyKubeczek wrote: post #46
wiz21c wrote: post #20

Earlier quoted context omitted.

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…

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

Re: A Proposal for an asynchronous Rust GUI framework

#59

Post by telotortium »

Animats wrote: post #57
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 The pattern I keep needing is single ownership with back pointers. That can be done with Rc and Weak, which pushes the checking to run time. I think it might be possible to do this statically with some extensions to the borrow checker. It's not keeping the forward and back links consistent that is hard. It's making sure that all code sections either have read access to owner and owned, or…

Have you submitted a proposal to the Rust team about this? It would be interesting to read.
Post reply on HN