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!

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.

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.

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.

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?

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.

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

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

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

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

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

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.

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

> You would want to GTK (or Qt) I would think to draw the top level window and perhaps system menus, etc. even though the UI itself is drawn using a GPU canvas.

No, you would want to draw for Wayland or X. GTK and Qt themselves don't burden with importing each-other to work, for example.

My guess is that they import GTK only to get a title bar on GNOME, as GNOME forces applications to render their own. They could go custom and cut the dependency but it never looks quite right when apps do that.

No. On Wayland all of that should be in the compositor. Window sizing and positioning can not be done by the apps, so it makes sense that the controls for that are drawn and handled by the WM. But Gnomes gotta gnome...

Are GTK/Qt memory safe now?

How about a few large dependencies and no little ones?

zed looks nice, but I am going to wait until the American port to use it.

> (disclaimer: I think bitcoin is dumb, but the market disagrees)

I believe that market is quite controversial. Most people know that bitcoin is a bit dump, but they buy it regardless because they believe they profit from it when they do that as part of larger group. A very interesting social experiment with the mix of market manipulation. It is less about stability, independence or usability of the currency, but more about the opportunity of profit.

The thing that irks me about slint is the use of the more restrictive GPLv3-only which prevents it from being incorporated into a project which is licensed GPLv3-or-later. I don't get why it is done like that.

Yes and no.

I just checked against Qt5 on ArchLinux. Core, GUI and Widget .so are all about 6mb each.

I concede that it's closer to 20mb after all but at the same time it's not a fair apples to apples comparison because those libraries provide you with so much more functionality than just the UI.

That would seem odd.. the QSS is completely orthogonal to the code generated by the UI tool.

I accept that sometimes you need to some tricks with it and sometimes the layout in the preview is not the same you get at runtime which is annoying.

But in my UIs I use hundreds of widgets and I can't even begin to think about the useless effort required to write all the code by hand vs. spending seconds to drag and drop widgets into their place visually in the GUI editor...

"Let's get the volume first, then worry about accessibility"

That's the typical answer to these questions. Unfortunately, unless you bake it in from day #1 that's not so simple to fix afterwards.

System76 runs their own fork of Iced and commits things back to Iced, but in practice this hasn’t been as much as people seem to think.

Accessibility falls under this: to my knowledge Cosmic has it, Iced does not.

Win32 is the native way, MFC and Windows Forms build on top Win32, UWP is also native as thin layer above Win32 and COM (with some extras).

WPF is managed, only uses a bit of Win32 and DirectX 9, everything else is rendered by itself.

On macOS you now have to account for SwiftUI, which sometimes uses AppKit views and sometimes uses its own renderer. Kind of similar to UWP.

iOS and Android definitely have native toolkits too.

Same model as Flutter which is a million times more pleasant to write and mature at this particular use case which I don’t actually think Rust is well suited to generally speaking.

Actually users think functionality is 1000x more important than what it looks like. Since making things look nice takes away dev time from functionality, what it looks like doesn't matter much (above some minimum expectation of course).

Emacs, which still uses CUI-incompatible keybindings and even key names from a keyboard that hasn't been made since the 01980s.

Videogames.

Excel still supports MS-DOS Lotus 1-2-3 "/" commands, although it certainly doesn't look like Lotus for MS-DOS.

Basically any software people care about is an exception to your rule.

> But for them consistent means consistent with the 20+ other applications they use on a daily base. So native.

This was probably true 20 years ago but is not true today.

The majority of apps your average (non-HN) user uses is actually on their phone and not using the native UI widgets.

On their desktop they’re using apps like Spotify, Slack, and Microsoft Office or Google Docs.

The average user of today is not using a lot of native apps.

> Your users want the file-dialog, window-chrome, menus etc consistent too. But for them consistent means consistent with the 20+ other applications they use on a daily base. So native.

I don't think what you posit is true at all, at least not in 2025. Windows itself has abandoned consistency between its native applications, with more custom and modern styling that looks nothing like what you get out of the box with Windows UI frameworks. Almost every piece of software currently running on my computer has custom chrome: the web browser, my VPN, VSCode, Discord, Steam, mouse driver, keyboard driver, laptop fan driver. The only one that doesn't is qbittorent, and it looks like a complete eyesore. It is quite literally the odd one out, so much for "consistent with 20+ other applications".

Maybe it's different in MacOS land, but from my perspective you're 20 years behind if your application is trying to blend in with the OS in any regard other than the corner in which the X button is located. That way of thinking went out of fashion decades ago, and good riddance to it because things look much better now. What I mentioned above is a pretty good representative sample of my daily use, and the more I think about other software I occasionally use, the more I am grateful that nobody else still thinks like this. LiveSplit and Asesprite come to mind as two applications that strongly benefit from having bespoke chrome and wouldn't be nearly as nice to use if they looked anything like a native Windows application. Of course, my own software uses custom chrome as well, because looking nice makes it more pleasant to use, wouldn't you know it.

Not just a sense of familiarity; you will simply never build the full spectrum of a file explorer's functionality in a custom file dialog, that would be a complete waste of engineering time. And many more users than you'd expect benefit from the fact that native file dialogs are actually full-fledged explorers. For example, I fairly often find myself quick-previewing a file to be sure it's the correct one when I select it.

Unfortunately not