2 ms·

The coroutine and communication by channels paradigm which Go introduced to me (I recognize that it is a very old paradigm, but it was new to me at the time) is

The coroutine and communication by channels paradigm which Go introduced to me (I recognize that it is a very old paradigm, but it was new to me at the time) is just so very easy for me to reason about.

unscaled 6y ago
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/

unscaled 6y ago

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/