gpui itself is spun out of the zed editor, so I'd say it probably has more real-world usage than the majority of rust UI crates
I'd be very surprised to learn that any other Rust UI crate has more real-world usage than GPUI!
Source:
https://sequoiacap.com/article/partnering-with-zed-the-ai-po...
The more salient metrics would be things like how many people know how to use the framework, the variety of use-cases its good for solving, how easy it is to hire or get help with it, etc. As for Druid, Druid is already officially unmaintained, its core developer having moved on to work on Xilem instead. (my experience, for the record, was positive, I very much enjoyed working with Druid.)
I wonder if there are more Cosmic Desktop + Kraken desktop users than Zed Editor users?
I actually tried to create a UI kit using zed's code for a personal project, but gave up.
nice to see I was not the only one with the idea and it can get some usage now. The example app looks awesome.
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!
And to be fair, not every great engineer is a great writer, artist, composer, or any other role one might like to have on board for making a game.
Nobody makes games in Bevy though, Bevy is just a very good, modern graphics tech demo, not something suitable for developing actual games. Even the biggest title out there, Tiny Glade, is just a level editor with precisely zero gameplay features. Bevy's "popularity" (on social media, not among game developers) is entirely hype-driven by people that do not actually make games at all.
I would agree with you that bevy is not fit for making a commercial game. but not because its not capable. Its just NEW. we are only now starting to see commercial games come out with godot and thats 11 years old. bevy came out what, late 2021? give it some time. It still needs more workflow tools, a level editor stable documentation and a bunch of other things.
It will get there. it just takes time.
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 time for a game engine to be ready to create the kind of experiences you're probably thinking about, and even if everything goes great with Bevy in the future, it's still probably years rather than months until any big studio will think of start using it for something important.
With that said, people are for sure making games in Bevy even if the experience is non-optimal. Search on GitHub for "bevy" and sort by latest update and you get a snapshot of the projects that are on GitHub, then imagine there is a magnitude more people working privately.
https://steamdb.info/stats/gameratings/2025/?min_reviews=500...
However, it doesn't even use Bevy's renderer, but their own: the devs mostly just care about its ECS. So it definitely isn't the showcase Bevy is looking for.
Bevy gets all the hype, but Fyrox has more maturity in a lot of surface area.
Bevy is led by a large team, and the leadership is ex-Google.
Fyrox is one solo Russian developer with 10x engineering output.
Bevy is ECS, Fyrox isn't.
Bevy does a great job marketing itself, it has a foundation and a large community, and people are excited to try and use ECS.
Are you trying to tell something more logical? Does the "Rust gamedev scene" affect the technical merits of libraries?
Doesn't mean bevy is better or anything, just that because it's so different people tend to flock to it.
But the lineup of high-quality games in production with Bevy just never stops to impress me. I'm always surprised by the new cool stuff they're making every time I take a peek at their community. Yes, most of them are not finished yet, but the engine is still young so that's understandable (gamedev can take years).
On the other hand, I'm still not really seeing any games being made in Fyrox despite it being a few months older than Bevy. Huge respect to the dev though, he's making great stuff.
But if I ever need to pick a pure Rust game engine at all, it's def going to be Bevy.
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.
Which UI crate did you use? The word "enterprise" caught my eye. So far I haven't found a Rust UI crate that I found rich enough, so I'm curious your experience.
Thanks for the reply.
In my case I did mean "I can write/maintain a UI rich/polished enough to pass as a 'shrink wrapped'"
I have a feeling iced would work similarly well but the documentation situation wasn't as good last I checked.
And if you're on Discord, the community is 10/10. I'm there all the time and always helping newcomers, and so are many others.
I do share screenshots and screen recordings every now and then in the iced Discord but I've so far refrained from posting about it on HN which is a much bigger audience
I suppose the best description of the UI is a mashup of VSCode and Figma
> https://github.com/longbridge/gpui-component/tree/main/crate...
> Just "cargo run --release"
Very impressive! Only thing I am concerned over is that it uses around 900 dependencies. But I don't know whether it much for GUI applications.
The other thing you can do (which is popular in the Bevy community) is to compiile the "core runtime" into dynamic library. Then you don't need to recompile that set of crates for incremental builds.
[0]: https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...
I'm curious as to what this means exactly. Are you saying keep the UI stuff in a separate crate from rest of app or ???. And just a separate or an actual dynlib? (wouldn't that imply C ABI? would make it a pain to interface with it)
It doesn't necessarily require C ABI. Rust doesn't make any guarantees about stability of the Rust ABI. But if you compile the app and the dynlib with the same compiler version then it works in practice (and IIRC there are enough things relying on this that this is unlikely to break in future).
That does mean you need to recompile the dynlib when you upgrade the compiler, but that is probably infrequent enough not to be a huge issue. Certainly if your aim is fast-recompiles in response to e.g. ui style changes then it ought to work.
--
A note on the sort of Rust compile times I see for a TodoMVC app using my Rust UI framework (412 dependencies):
- A clean release build (-O3) is 1m 01s
- An incremental (-03) rebuild is 1.7s
- A clean debug build (-O0) is 35s
- An incremental debug build (-O0) is 1s
That's on a 2021 MacBook M1 Pro which is fairly fast, but I hear the M4 machines are ~twice as fast. And that's also without any fancy tricks.
(dioxus-7-rc.3)
It usually only works when reordering elements, or changing static values (styles, attributes, etc).
Which, to be fair, does speed things up a lot when tinkering with small details.
But 70%+ or so of my changes still result in recompiles.
I've been able to get the hotpatching to work for use cases like "extract some UI code" into a new component that didn't exist before.
Note that the hotpatching is not enabled by default, you have to specify --hotpatch when running dx
I indeed was not enabling it.
I'll give it a try!
Yeah, although I would define "reversible computing" as how to deterministically undo some computation(s)/effect(s) etc without recording the control-flow and I do not like the notation of "time-reversibility", because distinguishing between "reversible computing with known timings" and "reversible computing with unknown timings" becomes very confusing. So I'd phrase it somewhat differently, but did not come up with better naming yet. Context: https://en.wikipedia.org/wiki/Reversible_computing and https://en.wikipedia.org/wiki/Time_reversibility.
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.
UPDATE: This honestly looks incredible and makes huge strides in the Rust UI landscape. You can run an impressive widget gallery app here showing all their components:
https://github.com/longbridge/gpui-component/tree/main/crate...
Just "cargo run --release"