Here's the thing about channels in go. They're a primitive. Just like int 
is a primitive and string is a primitive. They're not an entire library, or 
framework. they're just a primitive.

In other languages, currency "tools" are usually provided as some part of a 
fully featured library, or package, or framework. But not in go. Go 
provides the primitive, and its up to you to use that to implement your 
actual concurrency tools.

You might try to store a date in an int. But there are lots of caveats 
along with doing so. Instead you take primitives like ints and structs and 
put them together to make a package and set of structures for dealing with 
Dates. You don't complain that int alone isn't good enough for doing all 
your date processing.

But a lot of devs see the channel and assume its some high level 
abstraction built with an API to deal with all your common situations, 
because thats what they are used to expecting from their other language 
experience. Its not though. Its just a building block. Build something with 
it, and then use that something.

On Monday, August 7, 2017 at 11:01:12 PM UTC-7, snmed wrote:
> Hi Gophers
> I stumbled over a nice and very interesting Blog entry "Go channels are 
> bad and you should feel bad 
> <>"
> , I would like to hear some opinions about that article
> from seasoned go developers. Because I just used go for a couple of months 
> for my private web projects and rarely get in touch with channels.
> By the way, that article is not a rant and the author likes go very much 
> as far as I can conclude from the article.
> Cheers snmed

You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to