News for hackers. Stuff that matters.
Re:Rust’s async isn’t colored by majewsky on Thursday March 11, 2021 @07:46AM (#26423393)
One of the more widely deployed ones is Go. Code looks like with synchronous IO, but everything runs in green threads that can be suspended when IO would block. So if you do a File.Read, after it returns, you might be running on a different OS thread because you were suspended mid-Read and later woken up on a different thread. It's generally nice to work with, unless you need to interface with a non-Go library that expects you to use a single thread throughout (e.g. for callbacks), in which case suddenly everything turns into a royal mess.
Re:Rust’s async isn’t colored by pansa2 on Thursday March 11, 2021 @08:11AM (#26423582)
> everything runs in green threads that can be suspended when IO would block

AFAIK the main objection to this model is that you have to write your code so that it can handle being suspended at any point. OTOH when using async-await, the only potential suspension points are the places marked with `await`.

Re:Rust’s async isn’t colored by tedmielczarek on Thursday March 11, 2021 @11:37AM (#26425906)
Rust was originally built with green threads. The RFC that proposed removing them has an extremely detailed explanation of why the change was made pre-1.0: https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b...

I think this has proven itself to be the right decision. It's one of the main reasons that Rust works so well alongside other languages—there's very little default Rust runtime that complicates interop. There are also lots of programming scenarios for which green threads are not the right tool, and Rust accommodates those.

Re:Rust’s async isn’t colored by gpderetta on Thursday March 11, 2021 @08:37AM (#26423845)
I don't think that's a very strong guarantee though.

Trivially you can call any function that can block. Less trivially, any function that you can can resume any other suspended coroutine. So in practice there isn't much you can rely on. In general you can not rely on state that has escaped your function to be unmodified across function calls (although here of course rust has tools to prevent that, but they would work even without the sync/async distinction).

It is true that other code can only run at function call boundaries, but that's true for any cooperatively scheduled runtime, even with stackfull coroutines.