4 ms·
I found the Go solution for that issue a bit odd - channels aren't for data processing, they're synchronisation primitives. Using them the way they did in the a
by lazyjones 10y ago
I found the Go solution for that issue a bit odd - channels aren't for data processing, they're synchronisation primitives. Using them the way they did in the article ruined the piece for me, since it reads like a rather uninformed decision now.
- lentil 10y agoAre you sure they aren't intended for data processing? I've never heard that claim before, and the Go documentation seems to have a lot of examples of using channels in that way. (https://blog.golang.org/pipelines https://blog.golang.org/pipelines, for example; or https://tour.golang.org/concurrency/2 https://tour.golang.org/concurrency/2).
- lazyjones 10y agoLet me rephrase: not suitable for large amounts of data that need high throughput. It's easy to see that the overhead is prohibitive for applications such as in the article, if you just benchmark it. https://groups.google.com/d/msg/golang-nuts/LM648yrPpck/tv40LGEfAwAJ https://groups.google.com/d/msg/golang-nuts/LM648yrPpck/tv40...
- cube2222 10y agoThat's just not true. You often use channels for messages of various kinds, or for returning values in async code.