We’re almost back to if (MB_OK == MessageBoxA(…)) and other modal forms, just need to wait a little more for this ui insanity to end and life can be good again.
Show HN: Async UI: A Rust UI Library Where Everything is a Future
31–40 of 96 posts
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#32Could you compare it with Sycamore with a few bullet points?
I feel like it is pretty close even though you don't see the async exposed? L
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#33Earlier 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?
For speed and its modern language (and poorer ecosystem). People already program gui in c++ for this very reason. So what is this rant about exactly? The usage of async? It's a valid way to do it, not the only one but valid.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#34Earlier 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.
There’s plenty of domain specific desktop software that costs $5k-100k per seat per year that is horribly buggy to the point of crashing several times during the course of a professional’s average day. Stuff like Altium, Solidworks, Xpedition, COMSOL, and all the big name FPGA suites crashed all the damn time when I used them for nontrivial projects.
All of the above packages are so complex that it’s not possible to control downstream code that gets invoked by user action. Rust’s importance here isn’t in the memory safety but in the features that enable Rust’s guarantees, which can also be used to create and enforce complex logic and rules using the same type level concepts.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#35Earlier 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, 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 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).
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..)
In no way is the point of "async style" decoupling.. that we can do on a lot of levels with a lot of primitives.. especially this is very unneeded for UIs where you can decouple UI from Cpu processing from everything else with usually (depends, sure) two to three permanent threads.
On top of that, async style is horrible also for our mental models.. most clear code happens with simple control flow, classical threads (no matter if green or os) shine there because they stick to that model much more than async.
Async style was and is still mostly for performance, definitely not for decoupling and also not for the nicer programming model..
But yeah, motivations and sense nowadays sadly often gets lost over hype :(
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#36Earlier 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, 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 (TelemetrySpan.start()) { blah.read().andThen(x->send(url);}` it doesn't do what anyone would ever want. Hopefully Loom fixes it.
So the async and sync distinction is needed/useful if you have both.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#37Earlier 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…
> 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 other than Go) default stack size is in the order of kilobytes, allowing you to run millions of them concurrently.
Thread contention wastes CPU cycles on kernel-level context switches and may lead to hard-to-debug issues such as thread starvation. You generally have no control over how the OS scheduler manages OS threads, so without sophisticated thread synchronization mechanisms, you're relying on blind luck.
Userspace threads are usually scheduled by the language runtime itself, which gives it a higher level of control. For example, Go runtime schedules goroutine in a round-robin fashion, guaranteeing that all goroutines will have some kind of progress in a reasonable amount of time.
EDIT: Since this post is about UI, yeah, "classical" OS threads are pretty good choice, since you usually only need a single OS thread to handle all the UI events, while the rest of the system can do the processing. So both the "stack size" and "contention" arguments are not really relevant in that scenario.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#38Earlier 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…
> Async/await syntax is needed if you want to have a `with` block that managed resources across co-routine boundaries.
I don't see what is the connection between async/await syntax and managing resources. The `with` block is just another mechanism for managing resources - Go has the `defer` statement which runs the deferred function at the end of currently executing function block, providing the equivalent functionality without need for async/await syntax. The `with` blocks could easily be implemented in Go, but Go doesn't like duplicating functionality in the language.
> Consider Python's `async with`
Python is a traditionally synchronous language, so the async/await syntax in Python is necessary if you want to use the async runtime, while still having compatible syntax with the traditional sync runtime.
> So the async and sync distinction is needed/useful if you have both.
Every sync call can be trivially modeled as an async call that is always awaited. If you want to bolt-on async runtime onto a sync runtime, you need async/await syntax. Other than that, I don't see the value it brings to a language at all.
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#39has a SwiftUI resemblance, nice :)
Re: Show HN: Async UI: A Rust UI Library Where Everything is a Future
#40Earlier 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.
No post body was provided.