Was async fn a mistake? (seanmonstar.com)
from snaggen@programming.dev to rust@programming.dev on 29 Sep 2023 05:16
https://programming.dev/post/3655431

#rust

threaded - newest

RonSijm@programming.dev on 29 Sep 2023 06:16 next collapse

Semi-relevant: dotnet had an experiment a couple weeks ago to see whether green-threads (virtual, non-kernel threads) would be a better alternative to the async / await model:

github.com/dotnet/runtimelab/issues/2398
github.com/dotnet/runtimelab/…/greenthreads.md

The downside of async C# code is in that developers must decide which methods need to be async. It is not viable to simply make all methods in the program async. Async methods have lower performance, limitations on the type of operations that they can perform and async methods can only be called from other async methods . It makes the programming model complicated. What color is your function is a great description of this problem.

The key benefit of green threads is that it makes function colors disappear and simplifies the programming model. The green threads should be cheap enough to allow all code to be written as synchronous, without giving up on scalability and performance. Green threads have been proven to be a viable model in other programming environments. We wanted to see if it is viable with C# given the existence of async/await and the need to coexist with that model.

[…]

Conclusions and next steps

We have chosen to place the green threads experiment on hold and instead keep improving the existing (async/await) model for developing asynchronous code in .NET. This decision is primarily due to concerns about introducing a new programming model. We can likely provide more value to our users by improving the async model we already have. We will continue to monitor industry trends in this field.

runiq@feddit.de on 29 Sep 2023 06:19 next collapse

fn call(&self, req: Request) -> Future = async {
    // ...
}

Honestly, that’s not much better than the already working (but admittedly weird looking)

fn call(&self, req: Request) -> impl Future { async {
    // ...
}}

But I do agree with the gist of the article. Time to get out the 🍿 and hop on over to r/rust.

Edit: Lemmy’s markdown parser doesn’t appear to like ampersands in code fences, or angle brackets

Edit2: After reading u/cramertj’s response, it looks like lifetimes would complicate what I wrote above significantly. So… yeah, thanks for all the work, Sean and Tyler, it’s appreciated. 🙂

robinm@programming.dev on 29 Sep 2023 07:28 collapse

I totally get the = async { body } (and I think I would prefer it for everything since it makes one liner like fn add(a: i32, b: i32) -> i32 = a+b much nicer and compact). I can also get the "ignore associated type” part. But I fail to see why removing the impl in -> impl Future is useful.