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

Show HN: Async UI: A Rust UI Library Where Everything is a Future

wishawa.github.io

Post reply on HN
Print view View original

21–30 of 96 posts

Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future

#21

Post by TuringTest »

HippoBaro wrote: post #13

(Context: I write async rust professionally) Fly you fools. This will be a nightmare to debug, introspect and reason about for a speed boost that you (and your users) won’t be able to measure. If you want to build a native app, more power to you. There are simpler languages that will enable you to do that with a much higher productivity. Kudos to the library writer though!

The point of async APIs is not speed boost, it's decoupling processing from the local call stack (which happens to hang up the GUI until the routine resolves, but also forces components to be tightly coupled and monolithic).

IMO every end-user-facing interface should be based on async calls, which provides better composability and forces the developer to think the relations between all full possible interactions and not just the current call. Too many GUIs do weird things when the user clicks on several controls in quick succession before allowing the previous one to finish. The program should have a model for how to resolve such anomalous inputs, instead of leaving those interactions as undefined behavior or handling it as error-prone edge cases. Having an async framework isn't enough for that, but at least forces the developer to think about out-of-order interactions between commands.

If that makes reasoning about the complex it's because current debug & introspect tools are inadequate for async-heavy flows; but that's a reason to improve the tools, not to drop the flows. Better declarative languages and inspect tools would ease development in that style.

Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future

#22

Post by quietbritishjim »

TuringTest wrote: post #21
HippoBaro wrote: post #13

(Context: I write async rust professionally) Fly you fools. This will be a nightmare to debug, introspect and reason about for a speed boost that you (and your users) won’t be able to measure. If you want to build a native app, more power to you. There are simpler languages that will enable you to do that with a much higher productivity. Kudos to the library writer though!

The point of async APIs is not speed boost, it's decoupling processing from the local call stack (which happens to hang up the GUI until the routine resolves, but also forces components to be tightly coupled and monolithic). IMO every end-user-facing interface should be based on async calls, which provides better composability and forces the developer to think the relations between all full possible interactions and…

> The point of async APIs is not speed boost, ...

I think the parent comment meant using Rust rather than a garbage collected language like C# or even Java for a GUI. Not just using async within Rust.

Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future

#24

Post by sakex »

voorwerpjes wrote: post #17

Very cool! I don't understand the motivation about lifetimes in sync rust not being able to be arbitrary. I'm also confused because most of the time went you want to send data around in a async context you wrap it in `arc`, which has the pretty much analogous `rc` in a sync context which would also solve the lifetimes issue. Is there something I am missing?

In C++, this will compile:

    class T {
        public:
            T(int & m): member{m} {}
            int & member;
    }

    T MakeT(int m) {
        return T(m);
    }
    
    int main() {
        const auto t = MakeT(10);
        std::cout
Rust will correctly observe that the lifetime of m in `MakeT` is lower than the T object returned and will refuse to compile

Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future

#25

Post by davidatbu »

wishawa wrote: post #15
davidatbu wrote: post #12

So, does this work with an application that uses tokio?

This uses the executor used by async-std rather than the one used by Tokio. So if you're using something Tokio-specific, you would probably need async-compat[1]. But can you share more on what you need Tokio for? I'd completely understand if we're working with servers. But when it come to clients - UI applications - I feel like async-std and smol are pretty competitive. [1]: https://docs.rs/async-compat/

`reqwest` comes to mind as a client-side library that's my goto, that I think is tokio-only?

But I think the distinction you made about "client-side Rust" not being as obviously-tokio-dominated as backend-side does make me stop and think.

Btw, this looks interesting regardless! Great job! Can I ask how your Rust learning journey went? I assume one needs an under-the-hood understanding of async Rust to build a library like this, and I'd love to hear about your learning journey getting to that understanding.

Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future

#27

Post by Huh1337 »

quietbritishjim wrote: post #22
TuringTest wrote: post #21

Earlier quoted context omitted.

The point of async APIs is not speed boost, it's decoupling processing from the local call stack (which happens to hang up the GUI until the routine resolves, but also forces components to be tightly coupled and monolithic). IMO every end-user-facing interface should be based on async calls, which provides better composability and forces the developer to think the relations between all full possible interactions and…

> The point of async APIs is not speed boost, ... I think the parent comment meant using Rust rather than a garbage collected language like C# or even Java for a GUI. Not just using async within Rust.

Java GUIs are horribly slow. Maybe it's not inherent but I've never encountered one that wasn't. C# ones are sometimes alright but only if they're using the native Windows frameworks.

Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future

#28

Post by junon »

HippoBaro wrote: post #13

(Context: I write async rust professionally) Fly you fools. This will be a nightmare to debug, introspect and reason about for a speed boost that you (and your users) won’t be able to measure. If you want to build a native app, more power to you. There are simpler languages that will enable you to do that with a much higher productivity. Kudos to the library writer though!

Judging by this comment, I sincerely question what "professionally" means. You miss a lot of benefits and focus on the one thing that has very little to do with why people might want this.

Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future

#29

Post by bheadmaster »

TuringTest wrote: post #21
HippoBaro wrote: post #13

(Context: I write async rust professionally) Fly you fools. This will be a nightmare to debug, introspect and reason about for a speed boost that you (and your users) won’t be able to measure. If you want to build a native app, more power to you. There are simpler languages that will enable you to do that with a much higher productivity. Kudos to the library writer though!

The point of async APIs is not speed boost, it's decoupling processing from the local call stack (which happens to hang up the GUI until the routine resolves, but also forces components to be tightly coupled and monolithic). IMO every end-user-facing interface should be based on async calls, which provides better composability and forces the developer to think the relations between all full possible interactions and…

> 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 compiler more information so it can make stuff faster" (speed boost).

Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future

#30

Post by fastball »

junon wrote: post #28
HippoBaro wrote: post #13

(Context: I write async rust professionally) Fly you fools. This will be a nightmare to debug, introspect and reason about for a speed boost that you (and your users) won’t be able to measure. If you want to build a native app, more power to you. There are simpler languages that will enable you to do that with a much higher productivity. Kudos to the library writer though!

Judging by this comment, I sincerely question what "professionally" means. You miss a lot of benefits and focus on the one thing that has very little to do with why people might want this.

Why would people want to build a UI in Rust except for speed? Memory safety doesn't seem super important in the UI context.

There is a reason most people still refer to Rust as a "systems" language.

Post reply on HN