On Tue, Aug 8, 2017 at 8:01 AM snmed <sandro.p.da...@gmail.com> wrote:
> > 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. > > One way of putting it is that any synchronization/communication primitive will have an overhead in a system. Channels are "fairly expensive" compared to other methods. But if the processing you are doing is going to take orders of magnitude more time than the channel communication, then you can usually benefit from channels having some extra features in them, especially w.r.t. system correctness: they are often easier to program with. You can create an exaggerated situation: suppose you are in the EU and you decide that you want to distribute your system. You buy a server in Australia. Imagine you have a mythical failure free connection to Australia and you are doing RPC. You are easily looking at 300+ ms roundtrip times. If the task you execute on the Australian server is "add two numbers", then the 300ms overhead is a problem. But, if the task you are shipping to Australia is an NP-complete route planning you want solved to optimality, you are easily looking at hours of processing time. And then 300ms seems pretty quick! Channels work much the same, but the window is at the microsecond level. If you protect an operation in the nanosecond scale by a channel, then the channel overhead will dominate. But if you require milliseconds of processing time, then a channel is fairly cheap. Note that any communication to the outside world is likely to be on the millisecond scale, and that makes channels excellent as a tool to handle an operation which block on some foreign input. -- 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.
