Very nice writeup and thanks for the shout out at the end! Just curious, how do you count 5 concurrency models? Based on your link, I'd count three: Promises, Supplys, and Channels (and I probably wouldn't call them different concurrency models, since they're all basically actor-driven. But that may just be quibbling). And 3 approaches for concurrency doesn't feel like all that many compared to other languages (cf. JavaScript, which has at least that many).
Or are you counting the "low-level APIs" as concurrency models too? If so, that doesn't seem right. Any high-level abstraction will necessarily be built on something lower-level, and there's no reason to wall-off the lower-level API from end users – so long as it's marked as "should be avoided in user code", as those APIs are in the docs you linked.
Or maybe I'm just overthinking a joke :) Either way, thanks again for the post. Here's hoping it helps motivate me to actually blog a bit more myself!
Very nice writeup and thanks for the shout out at the end! Just curious, how do you count 5 concurrency models? Based on your link, I'd count three: Promises, Supplys, and Channels (and I probably wouldn't call them different concurrency models, since they're all basically actor-driven. But that may just be quibbling). And 3 approaches for concurrency doesn't feel like all that many compared to other languages (cf. JavaScript, which has at least that many).
Or are you counting the "low-level APIs" as concurrency models too? If so, that doesn't seem right. Any high-level abstraction will necessarily be built on something lower-level, and there's no reason to wall-off the lower-level API from end users – so long as it's marked as "should be avoided in user code", as those APIs are in the docs you linked.
Or maybe I'm just overthinking a joke :) Either way, thanks again for the post. Here's hoping it helps motivate me to actually blog a bit more myself!