| ▲ | kaoD 5 days ago | ||||||||||||||||
Aren't green threads and async-await orthogonal concepts? As I understand it async-await is syntax sugar to write a state machine for cooperative multitasking. Green "threads" are threads implemented in user code that might or might not use OS threads. E.g.: - You can use Rust tokio::task (green threads) with a manually coded Future with no async-await sugar, which might or might not be parallelized depending on the Tokio runtime it's running on. - ...or with a Future returned by an async block, which allows async-await syntax. - You can have a Future created by an async function call and poll it manually from an OS thread. - Node has async-await syntax to express concurrency but it has no parallelism at all since it is single-threaded. I think no green threads either (neither parallel or not) since Promises are stackless? Is this a new usage of the term I don't know about? What does it mean? Or did I misinterpret the "but"? As a non-Haskeller I guess it doesn't need explicit async-await syntax because there might be some way to express the same concept with monads? | |||||||||||||||||
| ▲ | valcron1000 5 days ago | parent [-] | ||||||||||||||||
You don't need "monads" (in plural) since GHC provides a runtime where threads are not 1:1 OS threads but rather are managed at the user level, similar to what you have in Go. You can implement async/await as a library though [1] [1] https://www.cambridge.org/core/services/aop-cambridge-core/c... | |||||||||||||||||
| |||||||||||||||||