5 ms·

async rust is the worse async out there. I prayed that rust did not include a async at all. But the JS devs pushed it thru. That pretty much sealed my rust use.

async rust is the worse async out there. I prayed that rust did not include a async at all. But the JS devs pushed it thru. That pretty much sealed my rust use. Im still salty.

simonask 7mo ago
You know what, I’ve heard people say this and thought “OK, maybe these other languages with GCs and huge runtimes really do something magical to make async a breeze”. But then I actually tried both TypeScript and C#, and no. Writing correct async code in those languages is not any nicer at all. What the heck is “.ConfigureAwait(false)”? How fun do you really think debugging promise resolution is? Is it even possible to contain heap/GC pressure when every `await` allocates? Phooey. Rust async is doing just fine.
- palata 7mo ago
  How does it compare to Kotlin async? I find Kotlin generally hits a good balance across the board.
- usrnm 7mo ago
  Try golang, where they did the only sane thing: everything is async from the very beginning, no function colouring
  - simonask 7mo ago
    I think practical experience with Go reveals that this choice being “the only sane thing” is highly debatable. It comes with huge drawbacks.
    - usrnm 7mo ago
      Of course it has drawbacks, everything does, but my practical experience has been hugely in favor of what golang is doing, at least, in terms of cognitive load and code simplicity. It is very much worth it in many, many cases
- mrsmrtss 7mo ago
  In .NET 11 C# async management moved to the runtime, mostly eliminating heap allocations and also bringing clean stack traces. You really only need to think about ConfigureAwait(false) when building shared libraries or dealing with UI frameworks (even there you mostly don't need it).
  - simonask 7mo ago
    You speak in the past tense, but .NET 11 is not released yet at time of writing. Runtime-async is not the current reality.
    - mrsmrtss 7mo ago
      True, it's in preview currently, but actually .NET is already very efficient with async today also - https://hez2010.github.io/async-runtimes-benchmarks-2024/ https://hez2010.github.io/async-runtimes-benchmarks-2024/ (.NET9 tested here).
      - simonask 7mo ago
        Sure, it’s really fine for what it does, but it is not significantly easier to deal with than Rust async, and remains fundamentally unsuited in several scenarios where Rust async works really well.
- pjmlp 7mo ago
  Unless you are writing GUI code, ConfigureAwait() shouldn't be on your source code.
pjmlp 7mo ago
Not sure who pushed async Rust, but at least async JS does work without having to hunt down for runtimes, and naturally the answer is always Tokio.
- VorpalWay 7mo ago
  Usually the answer is embassy for me. And embedded systems vastly outnumber classical computers. Every classical computer includes several microcontrollers, every car, modern appliance, camera, toy, etc does too. Safe languages for embedded and OSes is very important. Rust just happens to be pretty good for other use cases too, which is a nice bonus. But that means the language can't be tied to a single prescribed runtime. And that it can't have a GC, etc.
  - pjmlp 7mo ago
    PTC and Aicas would disagree there. As might microEJ, Meadows, F-Secure, Astrobe and a few others.
    - VorpalWay 7mo ago
      > PTC and Aicas would disagree there. Never heard of either. You will have to expand on your reasoning. Microcontrollers do outnumber classical computers though, that is just a fact. So i don't see why there is anything to disagree about there. Even GPUs have helper microcontrollers for thermal management and other functions.
      - pjmlp 7mo ago
        They have been selling real time bare metal Java runtimes for embedded systems, widely deployed across weapon systems in battleships and missile tracking units, factory automation, satellites, and other similar systems for the last decades. I bet many of those helper microcontrollers, are still Assembly, compiler specific C, and if there is Rust support, most likely only no_std fits, thus no async anyway.

async rust is the worse async out there. I prayed that rust did not include a async at all. But the JS devs pushed it thru. That pretty much sealed my rust use. Im still salty.

simonask 7mo ago

You know what, I’ve heard people say this and thought “OK, maybe these other languages with GCs and huge runtimes really do something magical to make async a breeze”. But then I actually tried both TypeScript and C#, and no. Writing correct async code in those languages is not any nicer at all. What the heck is “.ConfigureAwait(false)”? How fun do you really think debugging promise resolution is? Is it even possible to contain heap/GC pressure when every `await` allocates? Phooey. Rust async is doing just fine.

palata 7mo ago
How does it compare to Kotlin async? I find Kotlin generally hits a good balance across the board.
usrnm 7mo ago
Try golang, where they did the only sane thing: everything is async from the very beginning, no function colouring
- simonask 7mo ago
  I think practical experience with Go reveals that this choice being “the only sane thing” is highly debatable. It comes with huge drawbacks.
  - usrnm 7mo ago
    Of course it has drawbacks, everything does, but my practical experience has been hugely in favor of what golang is doing, at least, in terms of cognitive load and code simplicity. It is very much worth it in many, many cases
mrsmrtss 7mo ago
In .NET 11 C# async management moved to the runtime, mostly eliminating heap allocations and also bringing clean stack traces. You really only need to think about ConfigureAwait(false) when building shared libraries or dealing with UI frameworks (even there you mostly don't need it).
- simonask 7mo ago
  You speak in the past tense, but .NET 11 is not released yet at time of writing. Runtime-async is not the current reality.
  - mrsmrtss 7mo ago
    True, it's in preview currently, but actually .NET is already very efficient with async today also - https://hez2010.github.io/async-runtimes-benchmarks-2024/ https://hez2010.github.io/async-runtimes-benchmarks-2024/ (.NET9 tested here).
    - simonask 7mo ago
      Sure, it’s really fine for what it does, but it is not significantly easier to deal with than Rust async, and remains fundamentally unsuited in several scenarios where Rust async works really well.
pjmlp 7mo ago
Unless you are writing GUI code, ConfigureAwait() shouldn't be on your source code.

pjmlp 7mo ago

Not sure who pushed async Rust, but at least async JS does work without having to hunt down for runtimes, and naturally the answer is always Tokio.

VorpalWay 7mo ago
Usually the answer is embassy for me. And embedded systems vastly outnumber classical computers. Every classical computer includes several microcontrollers, every car, modern appliance, camera, toy, etc does too. Safe languages for embedded and OSes is very important. Rust just happens to be pretty good for other use cases too, which is a nice bonus. But that means the language can't be tied to a single prescribed runtime. And that it can't have a GC, etc.
- pjmlp 7mo ago
  PTC and Aicas would disagree there. As might microEJ, Meadows, F-Secure, Astrobe and a few others.
  - VorpalWay 7mo ago
    > PTC and Aicas would disagree there. Never heard of either. You will have to expand on your reasoning. Microcontrollers do outnumber classical computers though, that is just a fact. So i don't see why there is anything to disagree about there. Even GPUs have helper microcontrollers for thermal management and other functions.
    - pjmlp 7mo ago
      They have been selling real time bare metal Java runtimes for embedded systems, widely deployed across weapon systems in battleships and missile tracking units, factory automation, satellites, and other similar systems for the last decades. I bet many of those helper microcontrollers, are still Assembly, compiler specific C, and if there is Rust support, most likely only no_std fits, thus no async anyway.