4 ms·

People talk about C++ suffering from its commitment to zero-cost abstraction, but the same thing applies to Rust async. While async may theoretically be the fas

People talk about C++ suffering from its commitment to zero-cost abstraction, but the same thing applies to Rust async. While async may theoretically be the fastest possible way to write asynchronous code, it feels like an order of magnitude more painful than the CSP/channel-based approached used in languages like Go and Clojure (and the upcoming Java Loom). Personally if I had to write async code that required anything other than the absolute minimum possible latency, I'd prefer to write Go, and I say that as someone who thinks Go's lack of generics was an absolutely terrible idea.

crabbygrabby 4y ago
Go now has generics. The performance of using them is hit or miss it seems. Your opinion is valid, but I would say, if you aren't juicing for the best performance, you can adopt easier patterns to async. There are comments on this post detailing how to go about doing that. Or yea use another language if you want.
- logicchains 4y ago
  >you can adopt easier patterns to async Can I do this without having to wrap half the libraries in the ecosystem if I want to use them without worrying about async? C# has that issue: the ecosystem buys heavily into async, so it can be hard to avoid it.
  - crabbygrabby 4y ago
    Probably depends on what you are using and trying to do. So I'll say 'maybe'.
- gjvnq 4y ago
  But Go still doesn't have enuns with data like in Rust.
gwbas1c 4y ago
I made the mistake of trying to learn Rust while doing async programming. IMO, when it comes to concurrent, it's a matter of picking your poison: Threaded Rust: No overhead of a GC, but overhead of context switches and multiple stacks. NodeJS: No overhead of context switches and multiple stacks, but the overhead of a highly optimized GC. (And I suspect that the GC can do tricks like run when the process is waiting on all tasks.) Some real data would be very interesting.
- klysm 4y ago
  There’s plenty of real world data. I forget the name of the website but web server benchmarks are pretty good at showing the differences.
  - bebop 4y ago
    Maybe this: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
    - klysm 4y ago
      Yes those are the ones I was thinking of, thanks!
- WuxiFingerHold 4y ago
  Unless you really need the best performance possible there're pretty good alternatives. Mainly C# or Go and soon JVM with Loom. Some numbers: https://web-frameworks-benchmark.netlify.app/result?l=rust,go,csharp https://web-frameworks-benchmark.netlify.app/result?l=rust,g...
  - Larrikin 4y ago
    Why the need to wait for loom when there is Kotlin and coroutines?
- kaba0 4y ago
  > No overhead of a GC, but overhead of context switches and multiple stacks. Is it really an overhead if it happens in parallel? You have real parallelism, not only concurrency.
int_19h 4y ago
Async in something like C# is much less painful precisely because it doesn't try to be a zero-cost (or at least as low cost as possible) abstraction. When the language can allocate stack frames on the heap implicitly as needed, and there's GC to clean them up, things "just work".

crabbygrabby 4y ago

Go now has generics. The performance of using them is hit or miss it seems. Your opinion is valid, but I would say, if you aren't juicing for the best performance, you can adopt easier patterns to async. There are comments on this post detailing how to go about doing that. Or yea use another language if you want.

logicchains 4y ago
>you can adopt easier patterns to async Can I do this without having to wrap half the libraries in the ecosystem if I want to use them without worrying about async? C# has that issue: the ecosystem buys heavily into async, so it can be hard to avoid it.
- crabbygrabby 4y ago
  Probably depends on what you are using and trying to do. So I'll say 'maybe'.
gjvnq 4y ago
But Go still doesn't have enuns with data like in Rust.

gwbas1c 4y ago

I made the mistake of trying to learn Rust while doing async programming. IMO, when it comes to concurrent, it's a matter of picking your poison: Threaded Rust: No overhead of a GC, but overhead of context switches and multiple stacks. NodeJS: No overhead of context switches and multiple stacks, but the overhead of a highly optimized GC. (And I suspect that the GC can do tricks like run when the process is waiting on all tasks.) Some real data would be very interesting.

klysm 4y ago
There’s plenty of real world data. I forget the name of the website but web server benchmarks are pretty good at showing the differences.
- bebop 4y ago
  Maybe this: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
  - klysm 4y ago
    Yes those are the ones I was thinking of, thanks!
WuxiFingerHold 4y ago
Unless you really need the best performance possible there're pretty good alternatives. Mainly C# or Go and soon JVM with Loom. Some numbers: https://web-frameworks-benchmark.netlify.app/result?l=rust,go,csharp https://web-frameworks-benchmark.netlify.app/result?l=rust,g...
- Larrikin 4y ago
  Why the need to wait for loom when there is Kotlin and coroutines?
kaba0 4y ago
> No overhead of a GC, but overhead of context switches and multiple stacks. Is it really an overhead if it happens in parallel? You have real parallelism, not only concurrency.

int_19h 4y ago

Async in something like C# is much less painful precisely because it doesn't try to be a zero-cost (or at least as low cost as possible) abstraction. When the language can allocate stack frames on the heap implicitly as needed, and there's GC to clean them up, things "just work".