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 > <http://www.jtolds.com/writing/2016/03/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 to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
