Goroutines are multiplexed onto multiple OS threads
This is what I was trying to convey, @xarvos. From my perspective, what an awaitable is isn’t as important as what it does. On each await, control is yielt back to the event loop, and based on this assumption concurrency is performed by putting whatever needing to be atomic between two await statements. If the event loop employs more than one thread, such assumption is thrown out of the window and the abstraction falls apart.
On the other hand, go just spawns a job in a thread pool and concurrency is entirely up to the language user. Go is designed to have go used with channels (although I’ve heard they aren’t the most performant, likely still better than CPython though) where all shared data are supposed to go through.
Consider a textbook example of multiple jobs writing to the same file. In Python you’d have an asynchronous write function, while in Go you’d have a goroutine looping infinitely to receive the content from a channel and perform the write.
IMHO compared to channels async/await is a higher level of abstraction, which allow a simpler implementation of job hierarchy (e.g. happy eyeballs as a case study) with the cost of allergy to parallelism. Nothing prevents using them together to get the benefits of both worlds, and Kotlin actually has that IIRC.