Live data from Hacker News

Rust cross-platform GPUI components

github.com

171–180 of 225 posts

Re: Rust cross-platform GPUI components

#171
post #2

This looks to be one of the most complete Rust UI creates (in terms of available widgets/components), but unfortunately has almost no usage (yet). I do see their docs are coming along now. Another very complete one is fyrox-ui used by the fyrox game engine: https://crates.io/crates/fyrox-ui . Again, not really used/known outside of fyrox. The Rust UI scene is maturing, but the most popular options (iced, egui, dioxus…

Fyrox is such a blackpill for me (makes me doubt the Rust gamedev scene), because Fyrox appears to be the most mature Rust game engine, but nobody uses it or cares about it. Instead everyone is excited about the Entity-Component-System in Bevy, but once all the rough edges of Bevy are smoothed out, people excited about the ECS are going to realize they don't actually want to make art, or create game mechanics, they w…

This is a bit of a microcosm of Rust OSS libs in general; the libraries that get the most PR, articles, popularity are often not the best ones. I see this in the rust embedded and GPGPU areas as well, for example.

The smell for me is if the library is designed based on a plan, or attempting to be X ecosystem in Rust instead of built around one or more practical piece of software, and evolving to meet the needs of these softwares.

With that in mind: I adore EGUI. I hadn't heared of GPGUI before, but because of its origin as being purpose built for the Zed editor, this immediately gives it credibility, and I'm excited about it!

Re: Rust cross-platform GPUI components

#172
post #142

Earlier quoted context omitted.

> Nobody makes games in Bevy though Obviously not true, latest Bevy Jam has ~100 submissions! They might not be the games you were thinking about, but they're games nonetheless. Beyond the game jams there are definitively people making games with Bevy too, but I don't think anyone of them gone mainstream (yet?) but it's a bit harsh to say no one is making games with Bevy when that's clearly not true. It takes a long…

I judge the viability of a game engine/framework based on its commercial success. This may be a bit harsh but the truth is that hobby game jams and games with complex gameplay features are two different kinds of games and the viability of Bevy for one does not automatically make it viable for the other. Bevy may be fun to use for a simple 30 minute platformer for a game jam, but try re-creating any of the big indie h…

I'm not sure what exactly you're expecting from a game engine that is not even yet six years from its first commit, but nevertheless - while it came out in 2024, not 2025, Tiny Glade[0] is built with Bevy.

https://steamdb.info/app/2198150/

Re: Rust cross-platform GPUI components

#173
post #2

This looks to be one of the most complete Rust UI creates (in terms of available widgets/components), but unfortunately has almost no usage (yet). I do see their docs are coming along now. Another very complete one is fyrox-ui used by the fyrox game engine: https://crates.io/crates/fyrox-ui . Again, not really used/known outside of fyrox. The Rust UI scene is maturing, but the most popular options (iced, egui, dioxus…

> The Rust UI scene is maturing, but the most popular options (iced, egui, dioxus, slint, etc.) aren't even the most complete component-wise atm as far as I can tell. I think part of the issue is that they're still changing so much as we speak. But there's real momentum here and n=1 but I've been able to build incredibly rich, enterprise-ready UI with Rust today.

Same! I am building a structural biology CAD-like tool in Rust (EGUI + WGPU), and it's a great experience.

Re: Rust cross-platform GPUI components

#174
post #136

Earlier quoted context omitted.

There are two primary issues. In game development, for developing game features, iteration speed is the most important factor, you usually want a higher level scripting language in your game engine, so that a developer's workflow looks like this: make a simple change, hit a reload button, issue a few inputs, go back to the editor, make a simple change, repeat. Other popular game engines, more or less, solve this prob…

Have you tried using Bevy? I have used it for some pretty non-trivial use-cases (not open source), and I have found that I did not have to use the typical "RefCell >>>" stuff you talk about. There are paradigms in place for safe mutable access to the game state without jumping through hoops.

Of course you no longer have to actually try anything and give it a good-faith evaluation before criticising it. If it's different, then it de facto sucks.

This stance is not necessarily wrong - life is short, after all, and not every cup of tea has to be drunk from - but it does make finding useful criticism in a haystack of generic talking points rather difficult.

Re: Rust cross-platform GPUI components

#175

Earlier quoted context omitted.

> I did mean "I can write/maintain a UI rich/polished FWIW, you wrote that you actually HAVE done so, not just that you think you could: " but I've been able to build incredibly rich, enterprise-ready UI with Rust today. " Unless one has actually done so, and maintained/extended over a period of time, and not solo but with others, I don't know that one can be certain that a UI toolkit is good enough; certainly, it wo…

I have built it. It hasn't existed for long enough for me to say I've maintained it for an extended period of time, but then again I did not claim that. Nor did I use the word "certain". There's no certainty in life. I hear your point, but it's important to note I'm not making those claims and I don't think all of that needs to be true for it to be some value of "enterprise-ready". You and I may disagree on the meani…

Can you provide more details? Links to the implementation of available? Framework you used? Pain points?

Re: Rust cross-platform GPUI components

#176

Sad to see that the C++ community is sleeping on this. There are no modern GUI components or toolkits, specially under such a permissive license. Excited about the future of Rust GUI development, this is fantastic.

Azul.rs is making lots of progress now and it'll have decent C / C++ / Python bindings (so it won't be Rust-only). But I guess for now GPUI is more mature.

Re: Rust cross-platform GPUI components

#177
post #136

Earlier quoted context omitted.

Why? What does Bevy lack?

There are two primary issues. In game development, for developing game features, iteration speed is the most important factor, you usually want a higher level scripting language in your game engine, so that a developer's workflow looks like this: make a simple change, hit a reload button, issue a few inputs, go back to the editor, make a simple change, repeat. Other popular game engines, more or less, solve this prob…

> in Rust you have to do some shenenigans with things like RefCell>>> which is simply not very ergonomic

The entire raison d'être of Bevy and the reason it is built how it is is that the ECS eliminates that. If your Bevy code contains something that looks like that, you are using it very wrong. You put the data in the ECS, and any gameplay code goes into some system that uses the queries to pull the data it needs out of it. If you need something like a backreference, you don't add one in an unholy tower of refcells, you just use a different query.

If you wanted to argue that a soup of mutually referencing objects is easier to deal with than having to use a query system, I'd disagree, but you'd have a valid argument. What you posted above just highlights that you don't know much about bevy.

Re: Rust cross-platform GPUI components

#178
post #118
post #110

Earlier quoted context omitted.

Easy, similar to Qt. Don't want to pay upstream? Also don't get to charge money. Want to pay up stream? Another license can be arranged where both parties get to earn money.

I think you misread the post you're replying to. GP is complaining about it being incompatible with "GPLv3-or-later" Free Software, not with commercial or permissive OSS.

Yes, and being incompatible with GPLv3-or-later may be done on purpose to push folks into a commercial license.

Re: Rust cross-platform GPUI components

#179

Sad to see that the C++ community is sleeping on this. There are no modern GUI components or toolkits, specially under such a permissive license. Excited about the future of Rust GUI development, this is fantastic.

> Sad to see that the C++ community is sleeping on this. There are no modern GUI components or toolkits, specially under such a permissive license.

I'm not sure what you are talking about (there are plenty of x-platform C++ GUI toolkits with components). Maybe you mean "accelerated toolkits"?

Re: Rust cross-platform GPUI components

#180
post #142

Earlier quoted context omitted.

I judge the viability of a game engine/framework based on its commercial success. This may be a bit harsh but the truth is that hobby game jams and games with complex gameplay features are two different kinds of games and the viability of Bevy for one does not automatically make it viable for the other. Bevy may be fun to use for a simple 30 minute platformer for a game jam, but try re-creating any of the big indie h…

I'm not sure what exactly you're expecting from a game engine that is not even yet six years from its first commit , but nevertheless - while it came out in 2024, not 2025, Tiny Glade[0] is built with Bevy. https://steamdb.info/app/2198150/

Only the ECS.
Post reply on HN