Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust cross-platform GPUI components

github.com

Post reply on HN
Print view View original

41–50 of 225 posts

Re: Rust cross-platform GPUI components

#41

Post by nicoburns »

mdhb wrote: post #28
nu11ptr wrote: post #16

Earlier quoted context omitted.

Pretty sure native as in "not web". AFAIK, everything is drawn using the various GPU APIs (GPUI started with Metal on macOS, for example).

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.

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.

Re: Rust cross-platform GPUI components

#42

Post by matu3ba »

nu11ptr wrote: post #2

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

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 ?

Re: Rust cross-platform GPUI components

#43

Post by nicoburns »

UndyingHorse wrote: post #7

Why is the average binary size 10MB? Does it embed ICU data?

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

Re: Rust cross-platform GPUI components

#44

Post by nicoburns »

nu11ptr wrote: post #34
nicce wrote: post #29

Earlier quoted context omitted.

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

Re: Rust cross-platform GPUI components

#45

Post by galangalalgol »

airstrike wrote: post #33
nu11ptr wrote: post #26

Earlier quoted context omitted.

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.

Re: Rust cross-platform GPUI components

#46

Post by nu11ptr »

nicoburns wrote: post #44
nu11ptr wrote: post #34

Earlier quoted context omitted.

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/s…

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

Re: Rust cross-platform GPUI components

#47

Post by bezbac »

agluszak wrote: post #5

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!

gpui itself is maintained by the folks at https://zed.dev.

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: https://longbridge.com/desktop/

Re: Rust cross-platform GPUI components

#48

Post by _bent »

fidotron wrote: post #15

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.

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

Re: Rust cross-platform GPUI components

#49

Post by keyle »

mdhb wrote: post #28
nu11ptr wrote: post #16

Earlier quoted context omitted.

Pretty sure native as in "not web". AFAIK, everything is drawn using the various GPU APIs (GPUI started with Metal on macOS, for example).

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.

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.

Re: Rust cross-platform GPUI components

#50

Post by nicoburns »

nu11ptr wrote: post #46
nicoburns wrote: post #44

Earlier quoted context omitted.

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/s…

> 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 inter…

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.

Post reply on HN