6 ms·

> async/await is also available in a bunch of other languages, including F#, C#8, Haskell[...] Haskell (GHC) does not provide async/await but uses a green thre

> async/await is also available in a bunch of other languages, including F#, C#8, Haskell[...] Haskell (GHC) does not provide async/await but uses a green thread model.

LtWorf 11mo ago
How are green threads implemented?
- whatevaa 11mo ago
  A runtime with it's own scheduling. Something rust doesn't want to require.
kaoD 11mo 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 11mo ago
  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/content/view/A369E310ADAE4455020C918FC1D47958/S0956796899003342a.pdf/poor_mans_concurrency_monad.pdf https://www.cambridge.org/core/services/aop-cambridge-core/c...
  - kaoD 11mo ago
    What do you mean with "in plural"?
    - valcron1000 11mo ago
      In the sense that you only need to work with the standard IO monad to get the benefits of the runtime.
Yoric 11mo ago
(author here) Well, I haven't used Haskell in a few years, so I could absolutely be wrong. That being said, I'm almost sure that I saw a presentation by Simon Marlowe 15-20 years ago demonstrating GHC with a multicore scheduler (alongside `seq` and `par`). Also, from the very same Simon Marlowe, there's a package called `async` https://hackage.haskell.org/package/async https://hackage.haskell.org/package/async which basically provides async (no await, though).

> async/await is also available in a bunch of other languages, including F#, C#8, Haskell[...] Haskell (GHC) does not provide async/await but uses a green thread model.

LtWorf 11mo ago

How are green threads implemented?

whatevaa 11mo ago
A runtime with it's own scheduling. Something rust doesn't want to require.

kaoD 11mo 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 11mo ago
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/content/view/A369E310ADAE4455020C918FC1D47958/S0956796899003342a.pdf/poor_mans_concurrency_monad.pdf https://www.cambridge.org/core/services/aop-cambridge-core/c...
- kaoD 11mo ago
  What do you mean with "in plural"?
  - valcron1000 11mo ago
    In the sense that you only need to work with the standard IO monad to get the benefits of the runtime.

Yoric 11mo ago

(author here) Well, I haven't used Haskell in a few years, so I could absolutely be wrong. That being said, I'm almost sure that I saw a presentation by Simon Marlowe 15-20 years ago demonstrating GHC with a multicore scheduler (alongside `seq` and `par`). Also, from the very same Simon Marlowe, there's a package called `async` https://hackage.haskell.org/package/async https://hackage.haskell.org/package/async which basically provides async (no await, though).