10 ms·

(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

(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!

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.
  - Huh1337 4y ago
    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.
    - dboreham 4y ago
      Like IntelliJ?
      - Huh1337 4y ago
        Yes, exactly
- 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 ago
    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 :(
    - jen20 4y ago
      > Async style was and is still mostly for performance, Scalability, not performance.
junon 4y ago
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.
- fastball 4y ago
  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.
  - rat9988 4y ago
    > 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.
  - akiselev 4y ago
    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.
  - junon 4y ago
  - mcherm 4y ago
    > 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.
teknopurge 4y ago
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....
dboreham 4y ago
+100 It's time for us to take the institution back from the lunatics.

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.
- Huh1337 4y ago
  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.
  - dboreham 4y ago
    Like IntelliJ?
    - Huh1337 4y ago
      Yes, exactly
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 ago
  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 :(
  - jen20 4y ago
    > Async style was and is still mostly for performance, Scalability, not performance.

junon 4y ago

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.

fastball 4y ago
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.
- rat9988 4y ago
  > 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.
- akiselev 4y ago
  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.
- junon 4y ago
- mcherm 4y ago
  > 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.

teknopurge 4y ago

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....

dboreham 4y ago

+100 It's time for us to take the institution back from the lunatics.