I always dreamt of a GUI library where every widget would be a separate actor sending and receiving messages.
Show HN: Async UI: A Rust UI Library Where Everything is a Future
51–60 of 96 posts
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#52Earlier quoted context omitted.
And why no just "classical" OS threads? Yeah, that's rhetoric, sure you can (or did you mean that with virtual one's?) And actually once upon a time, one of rust's selling point that you could do that safely without the common data races that you have to care for in the usual multithreading/multiprocessing environments, awesome! So to your grandposter..: > The point of async APIs is not speed boost, it's decoupling p…
> And why no just "classical" OS threads? Because of memory footprint and thread contention. OS thread's default stack size is often in the order of megabytes. On a server with 64GB of ram, that means you can't run more than ~64000 threads at once. That's not really a high number in the context of modern highly-concurrent servers. Meanwhile, goroutine's (and probably green thread's and virtual thread's from languages…
> On a server with 64GB of ram, that means you can't run more than ~64000 threads at once. That's not really a high number in the context of modern highly-concurrent servers.
Obviously the OS does not allocate megabytes of actual physical RAM to thread stacks, it's just address space. Just, this:
https://unix.stackexchange.com/questions/127602/default-stac...
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#53I always dreamt of a GUI library where every widget would be a separate actor sending and receiving messages.
This is basically how Objective-C worked, being based on Smalltalk. Especially with NSNotificationCenter, you also get the async aspect (so-called “NSNotificationCenter spaghetti code”).
Personally I have mixed feelings on it. ObjC/AppKit was clearly a step up from classic object UI toolkits built in rigid languages like C++, but I find React and its immediate-mode brethren far more enjoyable to work with precisely because there is no amorphous graph of actors sending messages to each other.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#54Earlier quoted context omitted.
> The point of async APIs is not speed boost, it's decoupling processing from the local call stack You can do the same with goroutines/green threads/virtual threads, without putting the burden of differentiation between sync and async functions on the programmer. The only argument for async/await syntax I've ever seen is either "it allows traditionally sync languages to use async" (compatibility) or "it gives the com…
Are we talking about Rust or async/await syntax in the abstract? Async/await syntax is needed if you want to have a `with` block that managed resources across co-routine boundaries. Consider Python's `async with` which will create a resource that is freed when the co-routine leaves the execution context. This is distinct from Java's try-with-resources which doesn't work with async code. So anytime you use `try (Telem…
That's an advantage of async vs manual CPS. Green threads/coroutines allow stack based resource handling without the syntactic complexity of async.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#55Hopefully I can find some time in my busy schedule to try this.
One thing I like is that the code appears to flow more like a console app than a GUI app. I've always found it's easy to create a quick-and-dirty console app; but if I want to do a quick-and-dirty UI (windows) app, it's much more time consuming.
This is because, with console IO, you can write your UI in a very linear manner. With UI (windows), it's much harder to write the code in a linear manner.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#56Earlier quoted context omitted.
> And why no just "classical" OS threads? Because of memory footprint and thread contention. OS thread's default stack size is often in the order of megabytes. On a server with 64GB of ram, that means you can't run more than ~64000 threads at once. That's not really a high number in the context of modern highly-concurrent servers. Meanwhile, goroutine's (and probably green thread's and virtual thread's from languages…
> On a server with 64GB of ram, that means you can't run more than ~64000 threads at once. That's not really a high number in the context of modern highly-concurrent servers. Obviously the OS does not allocate megabytes of actual physical RAM to thread stacks, it's just address space. Just, this: https://unix.stackexchange.com/questions/127602/default-stac...
I wouldn't call it quite "obvious" (it certainly didn't cross my mind), but thanks for the information. Quite interesting.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#57Seems a weird mix of async and callbacks spaghetti.
I´d expect an async UI to be in "immediate UI" style, e.g.:
async fn give_em_cookies(window:Win) {
win.title("Cookies!");
win.columnwise();
win.label("Which cookie do you like?");
let cookie = win.selector(&["Shortbread", "Chocolate chip"]).await;
win.label("When to you want to eat the cookie?");
win.rowwise();
if win.button("Now!").await { eat_cookie_now(cookie); }
if win.button("Later!").await { eat_coookie_later(cookie); }
if win.closed().await { no_cookie_eaten(); }
}
// the function represents the state machine that encodes
// the behaviour of the dialog box, which the caller gives to UI
// engine for rendering
ui.display(give_em_cookies(Window::new())).await;Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#58It's 2.56 MB gzip!
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#59i'm really curious about the UI performance. a very good way to get lower latency in my usually callback-driven code is to move to synchronous things as far as possible - every callback has a cost, and these costs really add up especially if you want as fast as a startup as is possible for your app. And every step in a coroutine in an event-driven system is pretty close conceptually to a callback, isn't it ?
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#60Today in "HN never used a reactive framework that is not React and is offended when UI is not written with Dear ImGui".
This is literally the exact style of SwiftUI and Jetpack Compose (down to the author having used the term fragment, I sure hope this isn't leftover trauma from being an Android developer), except written in Rust (hence having to deal with lifetimes in the middle, default parameters, lambdas being quite verbose and needing to move things, etc).
Not blocking the UI thread is mandatory if you ever want to make any kind of complex UI. If you're a web dev, well you only have one thread anyways, good luck, if you're on any other platform, interactions _cannot_ ever block the UI (unless you, yourself, update the UI to say it is blocked). Making this async is a good thing.
Stack traces are a problem, but then again they've been a problem in any remotely capable UI toolkit.
With ReactiveCell, it looks surprisingly similar to what Compose does, where modifying a State causes recomposition of everything observing it. Which means that it might be powerful enough one day to do the same things as Molecule (https://github.com/cashapp/molecule), or ComposePPT (https://github.com/fgiris/composePPT), where everything is a potential target and it interops really well with existing toolkits.