Communicating through channels is completely orthogonal to the type of coroutines (stackless or stackful). I would argue that Kotlin does channels strictly bett

Communicating through channels is completely orthogonal to the type of coroutines (stackless or stackful). I would argue that Kotlin does channels strictly better than Go, since Kotlin channels do not have any of the problem of Go channels[1]: 1. No blocking forever on nil channels (WTF?) 2. Close is idempotent: No panic when closing a channel twice. Now you don't require 1 or 2 extra channels to measure proper closing of every channel :) 3. Send and receive behavior on closed channel is consistent - a easy-to-handle exception on both cases. Go panics on one case and returns a nil value in the other. 4. You can check the closed status of channel. 5. There are non-blocking versions of send and receive. I haven't tried Rust channels yet, but I assume they also deal with these issues by having a sane API. Go was not a pioneer at all here - it just had a Google-level PR to push its "revolutionary" ideas. The concepts of channels is much older than Go. It's not a secret that channels are based on the CSP model by Tony Hoare, and Rob Pike has a long history of researching CSP and integrating CSP constructs into his languages while he was at Bell Labs[2]. Channels are not the possible construct here. I'd argue that earlier languages implemented channel-like constructs in a much safer and saner way: e.g. Erlang's actors or Ada's Rendezvous (which dates all the way bac to 1983!). [1] https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s... [2] https://swtch.com/~rsc/thread/ https://swtch.com/~rsc/thread/