Was async fn a mistake?
(seanmonstar.com)
from snaggen@programming.dev to rust@programming.dev on 29 Sep 2023 05:16 +0000
https://programming.dev/post/3655431
from snaggen@programming.dev to rust@programming.dev on 29 Sep 2023 05:16 +0000
https://programming.dev/post/3655431
#rust
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
[…]
Honestly, that’s not much better than the already working (but admittedly weird looking)
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. 🙂
I totally get the
= async { body }
(and I think I would prefer it for everything since it makes one liner likefn 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 theimpl
in-> impl Future
is useful.