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

41–50 of 96 posts

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

#41

Post by mcherm »

fastball wrote: post #30
junon wrote: post #28

Earlier quoted context omitted.

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.

> Why would people want to build a UI in Rust except for speed?

Lots of reasons.

* The developer is familiar with Rust.

* The rest of the project is written in Rust.

* The primary function of the app is something for which a library exists in Rust.

Sure, Rust is known for running fast and for memory safety. But that doesn't mean that it will never be used except for those two reasons.

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

#43

Post by mananaysiempre »

cottsak wrote: post #9

sigh how did we all survive before async UI... ¬‿¬

By building, say, cooperatively scheduled systems of active objects (actors) accepting arbitrary messages Smalltalk style, like Windows 1. Or preemptively scheduled systems of typed ones, like Symbian. It’s not like the classic approaches are that much simpler, is my point.

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

#44

Post by kwkelly »

wishawa wrote: post #10
lucasyvas wrote: post #7

Earlier quoted context omitted.

This pretty interesting - does it take inspiration from anything? I personally haven't seen anything like this. It would also be great to see example code for that - it's the most significant part where I was looking for more information but couldn't find it. Edit: A bit unrelated, but the tokio vs async-std split continues! Edit 2: How does error handling work? Is check_login a component or regular request?

The async control flow is not directly inspired by anything. It is a cool side effect of using async for everything that I myself only discovered once I started writing examples. Async UI as a whole is inspired by the simple fact that UI is an effect system[1], and async is also an effect system. [1]: https://en.wikipedia.org/wiki/Effect_system Re async split: Diversity promotes innovation :) Re error handling: There…

Crank.js uses async and races for control flow. It’s pretty interesting

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

#45

Post by jen20 »

throw827474737 wrote: post #35
bheadmaster wrote: post #29

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

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…

> Async style was and is still mostly for performance,

Scalability, not performance.

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

#46

Post by [deleted] »

sakex wrote: post #24
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

[deleted]

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

#47

Post by smnc »

jen20 wrote: post #45
throw827474737 wrote: post #35

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

> Async style was and is still mostly for performance, Scalability, not performance.

For a webserver, scalability (as in ability to handle a large number of concurrent request) is a performance metric. Speed of handling each one of those requests is another performance metric.

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

#48

Post by moonchrome »

throw827474737 wrote: post #35
bheadmaster wrote: post #29

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

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…

>NO, just no! Async or similar approaches were motivated by super parallel concurrency (classic example is connection handling for a webserver) to have better performance vs the overhead you'd have with os thread primitives (and even there, nowadays, that is just a motivation that is not always true anymore..)

No - that's completely wrong.

Event loops existed prior to them being popularised for IO scaling - they were used in GUI for way longer.

Async is just a way to transpose continuation based programming and the callback hell involved in dealing with event loops.

Writing UI code even in multithreaded code, without async, is a PITA because UI frameworks expect UI state to be updated on the UI thread - so you need to do work on thread X then schedule a callback on UI thread and update UI state. With async you just fire off a task, await with scheduler on the UI thread and you have linear code flow.

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

#50

Post by teknopurge »

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!

I was going to post similar. I respect all builders - but why. Similar to the Postgres WASM in a browser post from the other day. Why....
Post reply on HN