this post was submitted on 29 Sep 2023
31 points (97.0% liked)

Rust

6005 readers
7 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
top 3 comments
sorted by: hot top controversial new old
[–] RonSijm@programming.dev 18 points 1 year ago

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:

https://github.com/dotnet/runtimelab/issues/2398
https://github.com/dotnet/runtimelab/blob/feature/green-threads/docs/design/features/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 7 points 1 year ago* (last edited 1 year ago)
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 5 points 1 year ago

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.