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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.