6 ms·
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, b
by TuringTest 4y ago
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.
- quietbritishjim 4y ago> 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.
- bheadmaster 4y ago> 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).
- throw827474737 4y agoAnd 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 :(
- jen20 4y ago> Async style was and is still mostly for performance, Scalability, not performance.