Hacker News Reader

Comment by nu11ptr | Hacker News Reader

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, 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"

View on HN

> but unfortunately has almost no usage

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

As of August 2025, Zed had 150K monthly active users. That was before it supported Windows; the number is much higher now (although not publicly reported).

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

Iirc Cosmic Desktop uses Iced

Kraken seems to have a desktop application for trading made in Iced as well.

I wonder if there are more Cosmic Desktop + Kraken desktop users than Zed Editor users?

users is a finicky metric. When Palia came out, a game you most likely have never heard of, I wrote a desktop installer for it with Druid, which a few million people downloaded and used to install and run Palia. Only a handful of people worked on this codebase, maybe three or four while I was there, but principally me and one other engineer.

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

GPUI yes, but I'm not so sure about GPUI Component which is what I assumed the parent was talking about.

I don't know that it's all that meaningful to discuss the component library as if it were its own UI framework. None of the other rust UI frameworks have distinct component libraries with distinct usage data either

Oh thats why it looked so familiar.

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.

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 were just excited about a neat system (and in fairness, ECS is neat), but they never really wanted to do the things required for a game.

ECS hype and the traditional make a game/make an engine dilemma shouldn't be considered reasons to avoid the Fyrox library (or other Rust projects).

Are you trying to tell something more logical? Does the "Rust gamedev scene" affect the technical merits of libraries?

Perhaps you should read the comment again, your questions don't follow from it.

What makes Fyrox better than Bevy? I don't think the hundred people commenting under every Bevy point release on HN are thinking of the ECS. It has features and it has tools and it has games.

> because Fyrox appears to be the most mature Rust game engine, but nobody uses it or cares about it.

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.

That's OK though. Other people will then be able to use Bevy for actually making a game.

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.

> Other people will then be able to use Bevy for actually 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.

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 problem by providing a way to make gameplay features in a higher level language (GDScript in Godot, C# in Unity, BluePrints in Unreal Engine, often Lua with custom game engines), with Bevy, you make a change, and you rebuild the code, and often times, making a simple gameplay logic change (for a spell, an item, or some NPC interaction), will also change the ownership rules in case of Rust, because you may want to now access the same item mutably in two places or other things, and that requires you to restructure your simple script to appease the borrow checker, which also brings us to the second issue, in game development, a lot of bad practices, become good practices, take cyclic references for example, which are a common pattern in video games, in other lower level languages, or languages that allow embedding a higher level language, it's not that big of a deal, in Rust you have to do some shenenigans with things like RefCell<Vec<Rc<RefCell<Item>>>> which is simply not very ergonomic and adds a lot of development friction. A lot of people don't realize that game engine and gameplay programming are two vastly different things that have different requirements, and Rust is a poor fit for the latter.

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<Vec<Rc<RefCell<Item>>>>" 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.

> in Rust you have to do some shenenigans with things like RefCell<Vec<Rc<RefCell<Item>>>> 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.

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

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 hits released in this year and you will quickly realize how much friction Bevy/Rust create. In fact, of all the 619 successful (>500 reviews) games released in 2025 on Steam, can you point out at least one of them made in either Bevy or Fyrox?

https://steamdb.info/stats/gameratings/2025/?min_reviews=500...

> you will quickly realize how much friction Bevy/Rust create

For me the experience is completely the opposite. ECS as a pattern lets me build way larger games with more complicated and interesting gameplay than I could build before without ECS. It's something about about easy it makes to create de-coupled functions and being able to easily put things under automatic testing that makes the whole process so much smoother. Before moving to Bevy I mostly used Unreal Engine and on two projects Unity, FWIW.

> I judge the viability of a game engine/framework based on its commercial success. This may be a bit harsh

I don't think it's harsh at all, I'd do the same if I was trying to build mainstream games, and I think many other peoples do so to.

But that's also very different than "Nobody makes games in Bevy though" which is what you said at first, which is a lot less charitable than what you wrote in your comment now. I understand it's an exaggeration, but it reads as you're sour about it, rather than being interested in a conversation about it.

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.

I fail to see how that's particularly relevant, considering that this discussion started with the implication that ECS specifically is a neat fad that Bevy users will eventually get bored of.

And again, I am not sure what exactly people are expecting of a game engine that started development in 2019. Development of Tiny Glade itself started less than three years after Bevy's first commit, which was an obvious factor in Pounce Light building a custom renderer.

It's relevant because the post I replied to is misleading on its own.

How is it misleading? Even Unity and Unreal games often have parts of the engine modified or replaced, e.g. swapping built-in audio for fmod/wwise or built-in physics for something in-house. Pounce Light has discussed the fact that it's primarily the renderer that they replaced[0], and they are not the first, nor will they be the last studio to use a custom renderer.

If your criteria for "made with Bevy" is "every single system in the game must be from Bevy", then sure, you won't find a single Bevy game in existence. But you will also find a lot fewer Unity and Unreal games than you think.

0. https://80.lv/articles/exclusive-tiny-glade-developers-discu...

> Bevy is just a very good, modern graphics tech demo, not something suitable for developing actual games.

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.

Tiny Glade is a great sandbox that must not have been easy to implement, game or not.

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.

I mean I get this in theory.

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.

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!

For better or for worse fyrox is not something too novel/new. So people don't really see a reason to use it over godot or other engines.

Doesn't mean bevy is better or anything, just that because it's so different people tend to flock to it.

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

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

I think you'll find two definitions of enterprise ready. People who make UIs and are comparing a UI crate to see how it stacks up, and people who write business logic in rust and only care that they were able to make a gui work without switching to some other language. I would put my org in the second situation. Someone bought the thing and didn't complain so good enough I guess. We were using egui.

Ahh, gotcha. Yeah "enterprise" to me meant: "I can write/maintain a UI rich/polished enough to pass as a 'shrink wrapped' app to my end users".

Thanks for the reply.

FWIW that reply was from a different person :D

In my case I did mean "I can write/maintain a UI rich/polished enough to pass as a 'shrink wrapped'"

The notion of shrink wrapped software dates us I think? But to that end, I have elements of so many different native looks jumbled around in my head all the way back to amiga workbench (deluxe paint was the best), that anything without really obvious flaws like off centered text or unresponsive buttons feels shrinkwrappable to me. By my standard any of these looks is enterprise ready. I remember someone at MS looking at a gui made by a team my friend was on and mocking it for looking like it was out of tron with saturated colors on a black background in high contrast instead of "modern" 3d grey buttons. It looked a lot more like the linked UI than anything MS was producing at the time. So there is the fashion aspect of it. You want to stand out, but not too much. I think that is the aspect I'm unable to judge. If everything is in the first or second place I look, I just won't care.

> 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 would be hard to know what surprising edges and ergonomics there are to consider in one's evaluation.

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 meaning of that term, and that's fine.

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

I used the `iced` framework and I can't link to it because it's not available to the general public yet.

Pain points were learning to think in The Elm Architecture early on and creating very complex custom widgets of my own (think a spreadsheet editor, for example)

I made some tiny apps available on my github as I was learning Rust and the library. None really meet the enterprise grade hurdle but show some of what's possible with little code. If you spend a little while longer you can make them much more polished, obviously. I kept them "unpolished" so they would be even easier for beginners to follow

https://github.com/airstrike/iced_receipts

https://github.com/airstrike/pathfinder

I used `iced` but admittedly I also used a lot of elbow grease. Custom Theme, custom widgets and lots of passion to get it to look Just Right.

Cool. Any publicly available source code? If not, any screenshots at least? I'm curious as what Iced is capable of (with extra widgets/themes/etc. like you mentioned).

Cosmic is built on iced, so you could look what they achieved.

look into Cosmic Desktop and SniffNet as examples, both use Iced and IME are very high quality

Unfortunately it's closed source and we're invite-only at this point so I can't share, but hopefully in a few weeks

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

I've had a lot of success with egui. We've needed to do some weird stuff and I've always been pleasantly surprised to see that the API is expressive enough that we're always able to work within the bounds of the library. Great documentation too.

I have a feeling iced would work similarly well but the documentation situation wasn't as good last I checked.

The issue with the documentation is a lack of guides or tutorials, but the crate is 100% documented and I think the examples cover 100% of what 90% of people need. Looking at other apps helps too.

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.

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

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

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.

That did seem excessive to me as well. I do worry about the DX of trying to work on an app with this. After each edit, I would expect a solid compile time to simply try your work.

I don't think GPUI has it integrated yet, but Dioxus's Subsecond tool [0] implements binary hot-patching for Rust apps which can help alieviate this problem.

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

> The other thing you can do (which is popular in the Bevy community) is to compile the "core runtime" into dynamic library. Then you don't need to recompile that set of crates for incremental builds.

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)

An actual dynlib (containing the core framework crates that typically dont change between compiles (and which in C world might be installed as precompiled system libraries)).

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.

I did some quick research. I knew Rust ABI was unstable, but I didn't realize you could create Rust ABI dynlib and Rust would automatically dynamically link it. For intra-app it would work just fine. Neat. Link: https://stackoverflow.com/questions/75903098/dynamic-linking...

However, I don't see what advantage this gives. You are going to specify that dependency in your Cargo.toml just like any statically linked crate. Anything that would invalidate the cache for a static crate would invalidate it for a dynamic linked crate. Iow, it seems like separate crates are the magic here, not the linking type. What am I missing?

Thanks for the build stats. Those are helpful. I have an M1 Max currently.

UPDATE: Good points below. As a dynlib it would create a boundary for sure (no LTO, etc.). Worth playing with, thx.

> I don't see what advantage this gives

I believe it may "just" be faster link times. Which may seem minor, but link times can often dominate incremental compile times because it's a slow and (at least historically) serial step which is O(total code size) even if the actual compilation is incremental.

See mold's linking benchmarks: https://github.com/rui314/mold. It can be the difference between multiple 10s of seconds with traditional linkers vs <2s with newers ones.

There are few strategies for dealing with this:

1. Is just to use a faster multi-threaded linker. On Linux, lld, mold, and wild on Linux are all much faster than the traditional ld/gold (and the latter two another step above lld). On macOS, the new built-in ld64 is pretty good. Not sure what the state is on Windows: possibly lld is best?

2. Is dynamic linking as above. This seems to be faster even though the dynamic links need to resolved at runtime. I presume because at least the links wholly within the dynlib don't need to be resolved.

3. Is tools like Subsecond (https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...) which effectively implement incremental linking by diffing the symbols in object files.

Even in Dioxus the usefulness is somewhat limited right now though.

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

Are talking about the "hotreloading" or the "hotpatching"? (There are two separate mechanisms) The hotreloading just does RSX and assets, and is very fast, the hotpatching is a recompile (no getting around compiling Rust code), but it should be a faster one, and in many cases it should be able to maintain application state.

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

Ah, thanks for the hint.

I indeed was not enabling it.

I'll give it a try!

Incremental compiles should be fast.

Since you think the UI scene is maturing: Where do I find 1. design docs and 2. debugging infra docs (Validation, Testing, Stepping, Logging, Tracing, Recording, Scheduling, Reversal Computing as typical ones) and/or how to apply them ?

scheduling ??? what's that ? scheduling UI events ? Reversal computing ? What's that ? You meant reversible computing ?

Scheduling means to generate enumerations/combinations of possible ui events. If interleaving events are possible and to what degree, then providing a notion of that and/or at least documentation would be helpful.

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.

GPUI has a mature scheduling story, letting you “block” the main thread on spawned tasks with async/await. It also comes with a deterministic random test scheduler for driving out timing bugs.

Thanks. Sounds like a good developer experience attempt.

I downloaded the Longbride app they made with it. It looks like a real application! Fits in pretty well on Mac. Runs much more smoothly than Electron!

I’m so tempted to find out if Claude and friends can work with it, cause it’s new, rust and and unique

With the right workflow you can work with any language and library, by managing the context carefully and "showing-not-telling". I've worked with Claude Code and Codex on lots with Rust and Clojure, seems to not have any more issues than when I use Python.

In terms of its state now, how does it compare to EGUI?

Reply on news.ycombinator.com