_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Rust cross-platform GPUI components
aurintex wrote 3 hours 8 min ago:
This is really interesting. As a new Zed user, I've read about GPUI,
but have no insights.
Coming from years of working with Qt, I'm always fascinated by the
search for the "holy grail" of GUI libs. It's surprising how elusive a
true "write-once-run-everywhere" solution (that's also good) still is.
My main question is about your long-term, cross-platform vision: How
are you thinking about the matrix of Desktop, Web, and Embedded
systems? Qt (for all its baggage) made a real run at desktop/embedded.
Do you see GPUI components eventually covering all three, or is the
focus purely on desktop/web for now?
stephenlf wrote 17 hours 22 min ago:
Ah yes, a GUI component landing page with no pictures. Makes it tricky
to imagine what the GUI looks like
Trojanking wrote 17 hours 42 min ago:
good job !!!!
shmerl wrote 18 hours 52 min ago:
So how would it work on Linux let's say, it would need its own theming
to match system look and feel of existing DE?
Animats wrote 19 hours 47 min ago:
Unfortunately, it's a framework. That is, it demands to own the event
loop.
It has a type "Application" (This is Rust, don't get to say "it has a
class Application, which you subclass", but that's how it works.)
That's fine for a cold start where you do everything their way, but
tough
if there's already an event loop. egui, in contrast, is just a library
crate which needs to be called on each frame.
aryonoco wrote 20 hours 33 min ago:
Really interesting, and look forward to playing with it
However I find it bizarre that in the comparison table, Qtâs
licensing is described as âCommercialâ. Yes Qt is available under a
commercial license but itâs also available under LGPL 3.
Yes that means you can even build proprietary applications linking
against the LGPL license.
That makes that table misleading and borderline FUD.
criticalfault wrote 1 day ago:
Now that we can do a nice toolbar and components, somebody please make
a document canvas control so we can make a decent office suite.
andai wrote 1 day ago:
webview.load_url("https://drive.google.com");
phkahler wrote 1 day ago:
Does it support app development in other languages?
cultofmetatron wrote 1 day ago:
it happens to be my birthday today and this is one hell of a birthday
present right now. been itching to dive into making a desktop app in
rust and this looks amazing!
gnarlouse wrote 1 day ago:
So how stupid am I for asking how long it is before this is available
in the browser and all the DOM behavior is WASM?
klaussilveira wrote 1 day ago:
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.
pjmlp wrote 10 hours 34 min ago:
Qt is modern enough, still there are hardly any Rust libraries as
feature rich in capabilities and designer related tooling.
It is also the KDE infrastructure, used in plenty of infotaiment,
factory dashboards and medical devices.
lelanthran wrote 22 hours 46 min ago:
> 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"?
fschuett wrote 22 hours 52 min ago:
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.
ratatoskrt wrote 1 day ago:
No mobile support. I get that a desktop UI framework doesn't want to
target smartphones, but I think iPads (and bigger Android tablets) can
cope well with more traditional desktop paradigms.
ape4 wrote 1 day ago:
A link to toolkit (GPUI) since I don't see it mentioned...
URI [1]: https://www.gpui.rs/
sagacity wrote 1 day ago:
It's interesting to see more people building on top of GPUI. I recently
also saw [1] which looks fairly similar.
URI [1]: https://github.com/Augani/adabraka-ui
nu11ptr wrote 1 day ago:
This looks great too! Hopefully one or more of these component
libraries catch on and stay well maintained.
samiv wrote 1 day ago:
Do these "modern" UI toolkits not have visual editors for knocking up
the UI anymore?
One of the strengths of Qt based UIs is that the framework has IDE like
tools where creating UIs is just a matter of drag and dropping the UI
widgets into a layout. No need to write code by hand. Both QtCreator
and QtDesigner can support this workflow.
Secondarily this comparison table has several problems when it comes to
Qt.
* Their license is dual license LGPL *and* commercial.
* Minimum binary size is definitely not 20MB but less. In general
your apps distribution size depends on which features of the toolkit
you're using.
* Comparing "Syntax Highlighting" makes no sense...
QSyntaxHighligther is an interface by which you can add your own syntax
highlighting to any QDocument. You're welcome to use reg exps, parsers
(such as tree-sitter) or whatever you want there.
* QRichText supports markdown such as HTML.
wolvesechoes wrote 9 hours 30 min ago:
This is just meant to show how awesome their toolkit is, without the
goal of having fair comparison. They list chart widget, but they do
not list 3D chart widget, because then they would need to show that
they do not have it, but Qt does. Same for equivalent of
QGraphicScene etc.
Truth is Rust doesn't have, and will not have anytime soon anything
comparable to Qt or VCL/LCL. No amount of GitHub starts and "made in
Rust" disclaimers is going to change that.
tracker1 wrote 19 hours 38 min ago:
I would think you could absolutely create something like that with a
few steps on top of a relatively complete component library like
linked.
You would probably want an xml/markup representation of component
hierarchies, similar to other efforts, this can work with Rust with a
macro interface that replaces the render hierarchy with the component
structure format of this library. From there, you would need an
application to hot-mount the same markup "live" as part of an
interactive design tool.
In the end it wouldn't be much different than Glade, XAML or QT
Designer. That said, you have to build a foundation before you can
put solar panels on the roof.
fishgoesblub wrote 1 day ago:
They also note that Qt6 is not themeable which is completely wrong.
paulddraper wrote 1 day ago:
WYSIWG and code are almost always if not always not done well
together.
WD-42 wrote 1 day ago:
In my experience QT designer was awful to use. Itâs probably fine
if you are doing super vanilla layouts and widgets but as soon as my
team started implementing custom css (or whatever the qt equivalent
is called) things went off the rails. We pretty quickly abandoned to
the tool completely to write the ui files by hand. They ended up much
smaller and cleaner as a result. For some reason the designer seemed
to add loads of unnecessary cruft.
So yea I can understand why they arenât a priority.
samiv wrote 1 day ago:
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...
tredre3 wrote 1 day ago:
> * Minimum binary size is definitely not 20MB but less. In general
your apps distribution size depends on which features of the toolkit
you're using.
In my experience that point is absolutely correct. Qt is good but
big. You usually end up with 30-40MB of it.
Core, Gui, QML, Widget are 8MB each. For a Hello World you need 3 of
those. Maybe 2.
Yes you could build Qt yourself with various flags, or possibly do a
static build with LTO might help. But that's not the typical way Qt
is used.
samiv wrote 1 day ago:
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.
tredre3 wrote 1 day ago:
> because those libraries provide you with so much more
functionality than just the UI.
Comparing GPUI to Qt based only on what they offer gui-wise is
fair, in my opinion. What QtCore provides is sugar over C++: the
object model, the signal system, some data types, many helpers.
But the thing is, all of those things are in Rust already.
They're even in modern C++.
So comparing a Qt hello world that uses
QtCore+QtGUI+(QtQML|QtWidget) to a Rust GPUI hello world seems
fair to me. It's not like the author also counted QtNetwork,
QtSQL, QtSVG, QtHTML, etc.
pjmlp wrote 1 day ago:
They do, but you have to look into the right ones, from ex-Qt
employees, [1] You can make use of Figma integration for something
similar to Qt Design Studio.
Too many folks nowadays don't seem to fully understand how powerful
GUI designers for native code used to be.
You always get some arguments about pixel perfect positioning,
completly ignoring the fact most of them had layout managers
available, even VB pre-VB.NET (yes Windows Forms does support layout
managers).
URI [1]: https://slint.dev/
Arch-TK wrote 1 day ago:
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.
pie_flavor wrote 1 day ago:
GPLv4 could be the MIT license. GPLv3-or-later is a statement of
arbitrary trust towards the FSF. Corporations serious about
licensure, like SixtyFPS, aren't fans of that. (I don't think
I've ever seen GPLv3-or-later in the wild from non-GNU/FSF
software.)
Arch-TK wrote 19 hours 40 min ago:
GPLv3-or-later is pretty commonplace in the world of free
software even outside of GNU stuff.
pjmlp wrote 1 day ago:
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.
Arch-TK wrote 19 hours 44 min ago:
You can freely charge money with either GPLv3-only or
GPLv3-or-later.
I am not asking them to remove GPLv3-only and replace it with
MIT, I am asking them to use GPLv3-or-later.
aryonoco wrote 20 hours 9 min ago:
Qt is LGPL 3. Slint is GPL 3. There is a massive difference
there for a âlibrary â
But to be fair to Slint, they do have a free proprietary
license which can be used for developing proprietary
applications as long as itâs not considers in the
âembeddedâ space.
mrec wrote 1 day ago:
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.
kinjba11 wrote 22 hours 47 min ago:
Yes, and being incompatible with GPLv3-or-later may be done
on purpose to push folks into a commercial license.
Arch-TK wrote 8 hours 27 min ago:
GPLv3-or-later is currently almost the same as GPLv3-only
at the moment given there is no GPLv4.
The reason why it's not possible to include GPLv3-only code
in a GPLv3-or-later codebase is that the latter is more
permissive, allowing the FSF to release an updated version
of the GPL.
They won't make GPLv4 any less copyleft and more permissive
than GPLv3, if they ever do make one. At worst, the GPLv4
will cause some commercial user of the code to be even more
inconvenienced.
ruguo wrote 1 day ago:
It does look pretty solid, but whenever Iâm building a desktop app
with Rust, Tauri is always the first thing that comes to mind.
artursapek wrote 1 day ago:
It seems like trading applications tend to be what demands the
performance to push R&D like this for Rust GUI. My team at Kraken
worked on [1] which powers [2] , a very similar application. You can
definitely feel the difference in a Rust GUI vs. a web view. It can
maintain high frame rates doing so much on the screen at once.
URI [1]: https://iced.rs/
URI [2]: https://www.kraken.com/desktop
nu11ptr wrote 1 day ago:
Are any pieces of this open source by chance? (other than iced
itself)
artursapek wrote 1 day ago:
Unfortunately not
Keyframe wrote 1 day ago:
I'm interested in how's the battery life while running a thing ilke
this. Another thing I'm interested in does it support rendering to
texture.. usage being used as a texture on an object (monitor let's
say) in a game or rendered as a texture with opacity on a quad/triangle
over a screen as a UI layer or a HUD
daakus wrote 1 day ago:
A quick check with release build on macOS shows the component demo
has a non-zero energy impact in the background (per activity
monitor), but the input example has zero energy impact while in the
background. This is already better than many new from-scratch UI
libraries. The foreground impact is harder to measure.
WhyNotHugo wrote 1 day ago:
The simplest examples have over a thousand (literally) dependencies.
Amongst them, are GTK, GDK, pango, etc. It literally depends on another
toolkit, which is the weirdest thing IMHO.
iknowstuff wrote 1 day ago:
Would you rather have 1000 small, composable, auditable dependencies
or the same amount of code in a monolithic dump of .hpp files?
phkahler wrote 1 day ago:
How about a few large dependencies and no little ones?
iknowstuff wrote 22 hours 37 min ago:
No advantage to it. Worse quality code to gain what? A smaller
number hiding ultimately the same amount of code? Also, since the
unit of compilation is a crate, fewer opportunities for
concurrent compiling.
ploxiln wrote 18 hours 21 min ago:
A multitude of tiny dependencies has a multitude of solo
maintainers, who eventually walk away, or sometimes get
compromised.
A few big dependencies each have a team and a reputation that
has earned trust and established release process and standards.
If there's a serious problem in a small part of a big
dependency, there are a few trusted maintainers of the big
dependency who can be reached and can resolve it.
The theory of small dependencies was a good theory, 10 years
ago when js devs using NPM started the trend of making them
"as small as possible". But it really seems like the emergent
pattern is the opposite of what is claimed. These JS and Rust
projects end up taking longer to build and resulting in bigger
outputs. Instead of a couple of "huge" 200KB dependencies, you
end up with _thousands_ of 1KB dependencies including different
versions and alternative implementations, you end up with
megabytes of "accidental" code you don't really need.
And we can reason about why. In an ecosystem where something
has 1 to 3 large deps, well sometimes a dependency pulls in
another sub-dependency with code you don't need. But in an
ecosystem where something has 10 to 100 deps, this still
happens, but 50x more overall. It's a exponential trend: you
have 3 big deps that each have 2 big deps that each have 1 big
dep, vs you have 20 small deps that each have 15 small deps
that each have 10 small deps.
cmrdporcupine wrote 1 day ago:
Such is sadly increasingly the way with Rust projects.
dminik wrote 1 day ago:
Because of GNOME's insistence on not implementing Server Side
Decorations, you can't not depend on libadwaita. This is what I
imagine pull in all of the GTK dependencies.
nu11ptr wrote 1 day ago:
I think this is pretty common on Linux. 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.
phkahler wrote 1 day ago:
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...
tredre3 wrote 1 day ago:
> 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.
moralestapia wrote 1 day ago:
Are GTK/Qt memory safe now?
discreteevent wrote 1 day ago:
No. What is the likelihood of an attack on a desktop program via
memory unsafety?
moralestapia wrote 1 day ago:
>What is the likelihood of an attack on a desktop program via
memory unsafety?
Low.
What's the likelihood of someone entering your house if it's
unlocked?
Also low, and yet you lock it.
discreteevent wrote 1 day ago:
A desktop program is already in a locked house - your desktop
- which I can't login to.
moralestapia wrote 1 day ago:
[flagged]
Chris2048 wrote 1 day ago:
Do all desktop programs only ever run in "your house"?
lesuorac wrote 1 day ago:
Really high?
What do you run your browser as?
discreteevent wrote 1 day ago:
Browser runs complex untrusted code from the internet. Most
desktop programs don't do anything like that. The servo
programmers were riding a motorbike. Using Rust for a desktop
program would be more like wearing a crash helmet in a car.
georgeburdell wrote 1 day ago:
2 hours after it's posted on HN, the repo has its first "readme.md typo
fix" commit.
patrick4urcloud wrote 1 day ago:
very nice !
what about tauri versus this compoments ?
ayoubmdi wrote 18 hours 33 min ago:
Tauri uses a WebView to render the UI, GPUI uses (DirectX, Metal,
Vulkan) directly to render the UI... Blazingly Fast hehe.
miki123211 wrote 1 day ago:
Does this implement accessibility at all?
This is often a problem with Rust UI frameworks, they may look
beautiful, but the moment accesibility becomes a requirement, the whole
app needs to be scrapped and rewritten in something more mature.
tracker1 wrote 19 hours 29 min ago:
You might want to consider Dioxus if you want better accessibility in
a Rust app... though afaik, there's no component library as complete
as this one available.
andrewl-hn wrote 1 day ago:
Not really.
This UI toolkit is based on GPUI library build by Zed editor team,
and while they improve accessibility over time (like, improving
contrast and stuff), it's opaque to screen readers.
At the moment if you want to have good accessibility story you should
probably look at Slint or Qt (via cxx-qt, for example). And since
System 76 picked up Iced for their UI it should receive a11y-related
updates, too.
Klonoar wrote 1 day ago:
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.
pacificat0r wrote 1 day ago:
Yes
the_duke wrote 1 day ago:
Virtualized lists and tables are amazing!
So many UI frameworks don't have these and require building them
yourself...
h4ch1 wrote 1 day ago:
GPUI and GPUi components are the two things I'm watching very closely
while evaluating truly native GUI development.
Still waiting to see more general use before attempting to port my
Svelte UI for a Tauri application but it honestly looks incredible.
Big ups to the guy(s) at Longbridge.
h4x0rr wrote 1 day ago:
Hola, finally a good rust ui framework that's not dependent on web
Ygg2 wrote 1 day ago:
You mean outside iced, slint, egui, etc. ?
brainless wrote 1 day ago:
This looks very good from the screenshots. I will try this as quickly
as I can. I have been building with egui and have tried Iced, Slint and
Makepad.
I built (agentic coded) a stocks viewer app for Indian stock market
data: [1] . It was a fantastic experience as to how easily I could
build a GUI app.
My main product also uses egui: [2] . It used to have a web app
frontend and I moved to desktop app after the experiment with
Indistocks. The experience has been really good, also coded with
agents.
Desktop apps are fun and even on my somewhat old and slow laptop (i5
8th gen, 16 GB RAM, 2GB nvidia dedicated graphics), they are so much
faster than web apps on Chrome (on Linux). I want desktop apps to make
a big comeback, we could use so many old devices.
URI [1]: https://github.com/brainless/Indistocks
URI [2]: https://github.com/brainless/nocodo
fidotron wrote 1 day ago:
Is this native as in "not web" or native as in actually using native
text entry and scrolling widgets? There is quite a huge difference as
the Java world discovered.
_bent wrote 1 day ago:
macOS is the only OS you can write native applications for. On Linux
there are with GTK and QT two different GUI frameworks that could be
considered native on some distros.
And on Windows there are so many different frameworks and approaches
used by MS for the shell that even a Webview could be considered
native
rafram wrote 1 day ago:
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.
nicoburns wrote 1 day ago:
iOS and Android definitely have native toolkits too.
pjmlp wrote 1 day ago:
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.
_bent wrote 1 day ago:
According to Microsoft WinUi3 and WinUi2 are also native
URI [1]: https://learn.microsoft.com/en-us/windows/apps/winui/
pjmlp wrote 1 day ago:
Naturally, they build on top of UWP.
There are some details on what that exactly means, but I am on
the go for lengthy comments.
aryonoco wrote 19 hours 51 min ago:
None of which is used by for example the Office team, which
maintains their own UI Framework just for Office.
Which itself is not used by Teams, which uses
electron/WebView2, even though Teams is part of Office.
And letâs not forget about MAUI, which has its own
components and UI library, which as far as I know is not used
by anyone at Microsoft.
And Iâve heard from people at Microsoft that the future
story of .NET UI framework is âBlazor WASMâ. Is that
considered native? Probably not. But Iâd argue it should be
considered âfirst partyâ.
Letâs be honest, Microsoftâs UI framework landscape is a
mess.
pjmlp wrote 13 hours 34 min ago:
Moving goalposts, the point was what are the native APIs.
Office framework would not exist without Win32, and usually
it is made available on Win32, e.g. ribbon as common
control.
Xamarin was never used at Microsoft, how to expect the
rewrite to go any better. This acquisition was a mess,
almost everything from Xamarin is gone.
Again, not a native API.
Blazor only matters for Web applications and PWAs, unless
Windows turns into ChromeOS there is nothing native about
it.
aryonoco wrote 10 hours 23 min ago:
Blazor is only for web applications, until you run into
Blazor Hybrid, which doesnât produce web applications!
pjmlp wrote 9 hours 45 min ago:
That is marketing gimmicks trying to get additional
market share, and the current adoption failure of MAUI
customers, as teams leave Xamarin ecosystem after the
Xamarin.Forms to MAUI (incompatible) rewrite.
I give zero value to Blazor Hybrid, from my point of
view it doesn't exist.
meindnoch wrote 1 day ago:
Native as in "not web". No OS integration.
hsn915 wrote 1 day ago:
I think it's native as in "native executable".
GPUI is not "native OS widgets".
nu11ptr wrote 1 day ago:
Pretty sure native as in "not web". AFAIK, everything is drawn using
the various GPU APIs (GPUI started with Metal on macOS, for example).
mdhb wrote 1 day ago:
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.
written-beyond wrote 20 hours 28 min ago:
Yeah but sometimes you don't want to write connectors between
high performance code and convenient to use UI code.
I welcome this, I want to write cross platform lightweight UI
applications without going to C or C++.
keyle wrote 1 day ago:
I write both swiftUI and flutter daily. I think SwiftUI is the
winner if we're going to put names forward. But arguably, not
cross platform. But in terms of language adaptability for UI,
Swift is king.
saghm wrote 1 day ago:
> I think SwiftUI is the winner if we're going to put names
forward. But arguably, not cross platform.
I must have a very different understanding of the word
"arguably" than you. To me, it's arguable whether Swift itself
is a viable cross-platform language today. SwiftUI, on the
other hand, supports literally zero devices not manufactured by
Apple.
Is it really arguable that when people say "cross plaform" when
referring to a GUI framework, they aren't counting "both macOS
and iOS, but not any of Windows, Android, Linux, web"? It might
be accurate from an pedantic standpoint, but I have trouble
imagining a context where someone would bother using that
phrase as a qualifier if they understood it that broadly.
mdhb wrote 1 day ago:
I would say the opposite and it sounds like a personal
preference at which point I think lack of cross platform
compatibility ceases to anything else other than a major major
problem.
keyle wrote 17 hours 56 min ago:
I didn't explain myself well. The point I was trying to make
is the language of Swift is far more flexible than Dart. And
in terms of UI implementation, it then looks a lot more like
a DSL.
Because () are optional and a function call can look like
this Button { stuff }. Meanwhile in dart, it's lines, and
lines and indentation of 2 because it becomes a massive
manuscript. I hope that makes more sense.
nicoburns wrote 1 day ago:
Rust's definitely well-suited to writing the low-level
infrastructure pieces (the implementations of the renderer,
layout, text, etc). You really want something with fast and
predicatable performance there. Whether it pans out for writing
actual applications we'll have to see, but a lot of big popular
applications are written in C++ which is surely less suitable.
SilverSlash wrote 1 day ago:
I was expecting something ugly but these actually look beautiful!
wongarsu wrote 1 day ago:
Rust certainly needs more GUI component collections. There are lots of
GUI toolkits, but a comparatively small number of prebuilt components
you can use with any of them.
This collection looks quite useful, though the component list is mostly
indistinguishable from a list of components for a web framework. The
webview component is the only one that seems somewhat specific to
native applications. So for something like a file-open dialog you would
still have to pull in something like rfd [1] and lose styling
consistency
1:
URI [1]: https://docs.rs/rfd/latest/rfd/
berkes wrote 1 day ago:
> lose styling consistency
Yes. And that is (almost always¹) a good thing.
Only the designers of an app, product-owners etc. want their app to
"look consistent over platforms".
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.
¹ Obviously some software excepted. E.g. categories like "expert
software" like Blender, AutoCAD, Photoshop/CS, where dialogs must a)
be optimized for their niche workflow and b) remain consistent for
that user when they upgrade their OS or move between OSes. But that's
an exception. Your TODO-list app or PDF reader almost certainly is
not that.
amelius wrote 1 day ago:
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).
Aurornis wrote 1 day ago:
> 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.
rayiner wrote 17 hours 39 min ago:
> On their desktop theyâre using apps like Spotify, Slack, and
Microsoft Office or Google Docs
I donât know anyone who doesnât hate these apps.
tcfhgj wrote 1 day ago:
I still want native apps (including proper OS Integration) even
though I don't get them.
anonymous908213 wrote 1 day ago:
> 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.
rafram wrote 1 day ago:
> Maybe it's different in MacOS land
It is. Windows has always had consistency issues; macOS hasn't.
comex wrote 21 hours 4 min ago:
macOS doesn't have (many) consistency issues in the OS itself
or first-party apps. But when it comes to the third-party apps
people use? Totally inconsistent. Most of them are either
webapps accessed through the browser (Google Docs), webapps
accessed through Electron shells (Discord, Slack, Zoom,
1Password), or non-webapps that nevertheless have their own
bespoke UI (Adobe, Microsoft Office, browsers themselves other
than Safari). I'm not a fan of the situation, but that's the
way it is.
I do fully admit these consistency issues were less bad in the
past.
kragen wrote 1 day ago:
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.
nu11ptr wrote 1 day ago:
Even though most UI libraries now draw their own widgets some native
integration is almost always used/desired. Those integrations are
typically: keyboard short cuts, native system menu (macOS), native
file dialogs, and (sometimes) native context menus. I'm sure there
are others I'm forgetting, but these minimal integrations are a good
thing as they give the user some sense of familiarity.
filleduchaos wrote 1 day ago:
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.
tredre3 wrote 1 day ago:
Thankfully on Macos x and Windows, the file picker isn't provided
by the UI toolkit (though they usually provide abstract methods
of calling it, for convenience).
Linux is now working towards that goal as well, in the form of
XDG Desktop Portal. It puts the Desktop Environment (or third
party provider) in charge of providing services like the file
dialog/picker/chooser for better integration/coherence. It's not
been fully adopted yet, but I'm very excited about it because
GTK's file chooser is just awful and I want to provide my own to
those apps!
patwoz wrote 1 day ago:
You should always use the native file picker and not shipping your
own. Thatâs a good thing.
ramon156 wrote 1 day ago:
Although its still very vertically scoped for zed, I'm way more hyped
about this UI than iced, dioxus ui, gtk-rs, etc. because of how
complete it already is in an early stage.
Then again I love zed so I might be biased.
UndyingHorse wrote 1 day ago:
Why is the average binary size 10MB? Does it embed ICU data?
nicoburns wrote 1 day ago:
I can't speak for GPUI specifically, but in general for Rust UI
toolkits I'm seeing about 10-15mb for an O3 build with LTO enabled
and when including things like ICU data, a WGPU-based renderer, SVG
rendering support, and a "full fat" async HTTP client. More minimal
builds with features disabled and/or Os/Oz can bring that down to
more like 5mb.
(obviously you can also take things much higher by building more
functionality into your application, but that gives you an idea of
the kind of "base size" achievable).
berkes wrote 1 day ago:
> By default, Rust optimizes for execution speed, compilation speed,
and ease of debugging rather than binary size, since for the vast
majority of applications this is ideal. But for situations where a
developer wants to optimize for binary size instead, Rust provides
mechanisms to accomplish this.
URI [1]: https://github.com/johnthagen/min-sized-rust?tab=readme-ov-f...
agluszak wrote 1 day ago:
I find it sad that a lot of foundational open-source software is
created/maintained by trading/crypto/money laundering companies. But
OTOH it's great that they at least contribute _something_ to the
society!
kgraves wrote 1 day ago:
> I find it sad that a lot of foundational open-source software is
created/maintained by trading/crypto/money laundering companies. But
OTOH it's great that they at least contribute _something_ to the
society!
React is unfortunately becoming more foundational than this project,
and with it maintained by a company that was involved in the Rohingya
genocide in Myanmar, the Cambridge Analytica scandal and so on.
This makes crypto / trading companies look like angels compared to
what Facebook has done even though they made and open sourced React.
To that end, I don't see anything morally wrong with the former camp
of companies supporting open source, (trading/crypto) since they
didn't participate and amplify an actual genocide.
ecshafer wrote 1 day ago:
I don't believe that to be the case. The ecosystems where this is
most true would be Rust, which has a lot of crypto use, and maybe
ocaml from Jane Street. But for the most part I have to doubt this.
bezbac wrote 1 day ago:
gpui itself is maintained by the folks at [1] .
Also, Longbridge, who seem to be using this GPUI component library
for their Longbridge Pro [1] app, look to me like a regular online
brokerage company. What is your issue with that?
1:
URI [1]: https://zed.dev
URI [2]: https://longbridge.com/desktop/
ecshafer wrote 1 day ago:
zed looks nice, but I am going to wait until the American port to
use it.
bezbac wrote 1 day ago:
May I ask what you mean by this? For all I know, Zed Industries
Inc is incorporated in the US and funded by US venture capital.
BTW, I am not associated with zed in any way.
ecshafer wrote 1 day ago:
Its a stupid joke. Americans say Z==Zee, rest of the
Anglosphere says Z==Zed
bezbac wrote 1 day ago:
Thanks for the explanation :)
philipallstar wrote 1 day ago:
I doubt that a lot of it is.
baq wrote 1 day ago:
Bitcoin ethos (as in, the original 'banks are broken, let's fix
this') is kinda similar to the hacker ethos ('this thing/program is
broken, let's fix this'), so maybe this shouldn't be too surprising?
Short term pain for long term gain etc.
(disclaimer: I think bitcoin is dumb, but the market disagrees)
nicce wrote 1 day ago:
> (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.
kennydude wrote 1 day ago:
Looks great for those using Rust - however I do wonder how well this
works, if at all, under screen readers and other accessible tech?
andrewl-hn wrote 1 day ago:
Zed Editor (built on top of GPUI) is opaque to screen readers, so I
wouldn't have high hopes.
jeroenhd wrote 1 day ago:
Haven't tried running the code myself, but their API docs mention
accessibility at least: [1] Assuming the docs are correct, the UI
controls seem ARIA compliant as long as you bother implementing the
necessary descriptions and labels.
URI [1]: https://longbridge.github.io/gpui-component/docs/components/...
Oxodao wrote 1 day ago:
my #1 question each time I see a new UI framework
jacquesm wrote 1 day ago:
"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.
anthony-eid wrote 1 day ago:
Accessibility is apart of gpui roadmap.
pseudalopex wrote 22 hours 4 min ago:
> Unfortunately, unless you bake it in from day #1 that's not
so simple to fix afterwards.
wiz21c wrote 1 day ago:
at least I think egui has worked on that aspect...
unwind wrote 1 day ago:
That showcase application (other than Zed) looks awesome, but the very
fancy-looking home page [1] fails to have a one-liner explanation of,
uh, what the application does. Please consider fixing.
[1]
URI [1]: https://longbridge.com/desktop/
ribelo wrote 1 day ago:
"Multi-platform Support,
Professional Market Monitoring" imho is a good explanation
nicce wrote 1 day ago:
I guess they expect that most people come there from the top level
domain. ( [1] )
URI [1]: https://longbridge.com
nu11ptr wrote 1 day ago:
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: [1] . 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: [2] Just "cargo run --release"
URI [1]: https://crates.io/crates/fyrox-ui
URI [2]: https://github.com/longbridge/gpui-component/tree/main/crates/...
zaphirplane wrote 10 hours 25 min ago:
Iâm so tempted to find out if Claude and friends can work with it,
cause itâs new, rust and and unique
embedding-shape wrote 5 hours 20 min ago:
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.
rayiner wrote 19 hours 38 min ago:
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!
the__alchemist wrote 23 hours 22 min ago:
In terms of its state now, how does it compare to EGUI?
Buttons840 wrote 1 day ago:
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.
theLiminator wrote 22 hours 38 min ago:
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__alchemist wrote 23 hours 21 min ago:
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!
dicytea wrote 1 day ago:
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.
zelphirkalt wrote 1 day ago:
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.
diath wrote 1 day ago:
> 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.
debugnik wrote 22 hours 26 min ago:
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.
cultofmetatron wrote 1 day ago:
> 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.
embedding-shape wrote 1 day ago:
> 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.
diath wrote 1 day ago:
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?
URI [1]: https://steamdb.info/stats/gameratings/2025/?min_rev...
filleduchaos wrote 23 hours 18 min ago:
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.
URI [1]: https://steamdb.info/app/2198150/
the__alchemist wrote 22 hours 42 min ago:
Only the ECS.
filleduchaos wrote 22 hours 29 min ago:
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.
the__alchemist wrote 22 hours 5 min ago:
It's relevant because the post I replied to is
misleading on its own.
filleduchaos wrote 19 hours 41 min ago:
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.
URI [1]: https://80.lv/articles/exclusive-tiny-glad...
embedding-shape wrote 1 day ago:
> 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.
Tuna-Fish wrote 1 day ago:
Why? What does Bevy lack?
diath wrote 1 day ago:
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>>> 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.
Tuna-Fish wrote 22 hours 48 min ago:
> 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.
DarmokJalad1701 wrote 1 day ago:
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.
filleduchaos wrote 23 hours 14 min ago:
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.
echelon wrote 1 day ago:
> 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.
pie_flavor wrote 1 day ago:
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.
HelloNurse wrote 1 day ago:
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?
Chris2048 wrote 1 day ago:
Perhaps you should read the comment again, your questions don't
follow from it.
swiftcoder wrote 1 day ago:
> 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
hoppp wrote 17 hours 42 min ago:
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.
michaelmior wrote 1 day ago:
GPUI yes, but I'm not so sure about GPUI Component which is what I
assumed the parent was talking about.
swiftcoder wrote 1 day ago:
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
rtfeldman wrote 1 day ago:
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:
URI [1]: https://sequoiacap.com/article/partnering-with-zed-the-ai-...
zemo wrote 17 hours 43 min ago:
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.)
RMPR wrote 1 day ago:
Iirc Cosmic Desktop uses Iced
embedding-shape wrote 1 day ago:
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?
matu3ba wrote 1 day ago:
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 ?
wiz21c wrote 1 day ago:
scheduling ??? what's that ? scheduling UI events ? Reversal
computing ? What's that ? You meant reversible computing ?
matu3ba wrote 1 day ago:
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: [1] and [2] .
URI [1]: https://en.wikipedia.org/wiki/Reversible_computing
URI [2]: https://en.wikipedia.org/wiki/Time_reversibility
nathansobo wrote 1 day ago:
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.
matu3ba wrote 21 hours 37 min ago:
Thanks. Sounds like a good developer experience attempt.
nicce wrote 1 day ago:
> 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:
> [1] ...
> 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.
URI [1]: https://github.com/longbridge/gpui-component/tree/main/crate
nu11ptr wrote 1 day ago:
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.
adastra22 wrote 1 day ago:
Incremental compiles should be fast.
nicoburns wrote 1 day ago:
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]:
URI [1]: https://github.com/DioxusLabs/dioxus/tree/main/packages/...
the_duke wrote 1 day ago:
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.
nicoburns wrote 1 day ago:
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
the_duke wrote 1 day ago:
Ah, thanks for the hint.
I indeed was not enabling it.
I'll give it a try!
nu11ptr wrote 1 day ago:
> 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)
nicoburns wrote 1 day ago:
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.
nu11ptr wrote 1 day ago:
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: [1] 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.
URI [1]: https://stackoverflow.com/questions/75903098/dynam...
nicoburns wrote 1 day ago:
> 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: [1] . 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 ( [2] ) which effectively
implement incremental linking by diffing the symbols in
object files.
URI [1]: https://github.com/rui314/mold
URI [2]: https://github.com/DioxusLabs/dioxus/tree/main/p...
airstrike wrote 1 day ago:
> 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.
the__alchemist wrote 23 hours 17 min ago:
Same! I am building a structural biology CAD-like tool in Rust
(EGUI + WGPU), and it's a great experience.
nu11ptr wrote 1 day ago:
> 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.
Boxxed wrote 1 day ago:
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.
airstrike wrote 1 day ago:
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.
airstrike wrote 1 day ago:
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.
nu11ptr wrote 1 day ago:
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).
airstrike wrote 1 day ago:
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
chiffaa wrote 1 day ago:
look into Cosmic Desktop and SniffNet as examples, both use
Iced and IME are very high quality
criticalfault wrote 1 day ago:
Cosmic is built on iced, so you could look what they
achieved.
galangalalgol wrote 1 day ago:
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.
nu11ptr wrote 1 day ago:
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.
airstrike wrote 1 day ago:
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'"
andsoitis wrote 1 day ago:
> 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.
airstrike wrote 1 day ago:
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.
bbkane wrote 23 hours 5 min ago:
Can you provide more details? Links to the
implementation of available? Framework you used? Pain
points?
airstrike wrote 21 hours 41 min ago:
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 [1]
URI [1]: https://github.com/airstrike/iced_receipts
URI [2]: https://github.com/airstrike/pathfinder
galangalalgol wrote 1 day ago:
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.
DIR <- back to front page