3 ms·

> Calling the stackful coroutine model as offered by Go superior to stackless coroutines ("async/await") is highly controversial. Yes. Preference among program

by pansa2 6y ago

> Calling the stackful coroutine model as offered by Go superior to stackless coroutines ("async/await") is highly controversial. Yes. Preference among programmers for one model or the other appears close to 50/50. More languages seem to support stackless coroutines than stackful ones, although that could just be because they’re easier to retro-fit to an existing compiler/VM. It’ll be interesting to see which model new languages choose.

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

by pansa2 6y ago

naikrovek 6y ago

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/