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?

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...

What do you mean with "in plural"?

In the sense that you only need to work with the standard IO monad to get the benefits of the runtime.

(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 which basically provides async (no await, though).

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