Others have already answered to you, but maybe a bit more affirmation may help.
Concurrency and parallelism are different concepts.
Many many years ago it was easy to confuse them both because there were no parallelism. You had a single big core and CPU pipelines were much simpler.
I won't delve into details, although I found them fascinating, but concurrency and parallelism are different tools.
I confess I found the name "concurrency" not useful.
Concurrency allows you to transfer control from one piece of text (I mean executable code) to another while it waits for the return.
Parallel means instructions are being executed, well, in parallel.
The OS scheduler does not inspect the code, nor know that the next instruction will be a noop sleep.
Some languages with runtime environments provide basically functionality pra intercepting calls and nudging the OS.
Attempts in the past of requiring each application to be clear about sharing control but it failed. One single bad application could hang and compromise the entire system.
As a matter of fact, some RTOS uses this premise of development.
Async has been implemented by providing a runtime library which saves the context and swap tasks. The control is only hidden from the programmer.
I do not know about Golang, but I suppose coroutines are implemented in a different way, as it seems to me, that the compiler handles this. But I don't know.
Concurrency and parallelism are different concepts. Many many years ago it was easy to confuse them both because there were no parallelism. You had a single big core and CPU pipelines were much simpler.
I won't delve into details, although I found them fascinating, but concurrency and parallelism are different tools. I confess I found the name "concurrency" not useful.
Concurrency allows you to transfer control from one piece of text (I mean executable code) to another while it waits for the return.
Parallel means instructions are being executed, well, in parallel.
The OS scheduler does not inspect the code, nor know that the next instruction will be a noop sleep. Some languages with runtime environments provide basically functionality pra intercepting calls and nudging the OS.
Attempts in the past of requiring each application to be clear about sharing control but it failed. One single bad application could hang and compromise the entire system. As a matter of fact, some RTOS uses this premise of development.
Async has been implemented by providing a runtime library which saves the context and swap tasks. The control is only hidden from the programmer.
I do not know about Golang, but I suppose coroutines are implemented in a different way, as it seems to me, that the compiler handles this. But I don't know.