4 ms·
The idea of using channels for network RPC has come up before, and it's still a bad idea. As jerf points out in the /r/golang thread [1] and this [2] older thr
by lobster_johnson 9y ago
The idea of using channels for network RPC has come up before, and it's still a bad idea.
As jerf points out in the /r/golang thread [1] and this [2] older thread, Go channel semantics don't match network semantics. In particular, Go channels have exactly-once delivery, which is impossible to do over the network.
Go channels are designed for communicating between goroutines; they work more like a signaling mechanism than a data pipe mechanism. They have too many design trade-offs to be practical for anything else. They're terrible as general-purpose queues and pub/sub-style topologies, for example. It's tempting to use channels are "iterators" because of range{}, but that's also a terrible idea. Buffered channels should be avoided unless you know exactly what you're doing. And since unbuffered channels block on send, you have to be super careful about goroutine interdependencies; the only way to avoid causing receivers to block senders is to wrap the send call itself in a goroutine, but if you do have slowness, you can accidentally fork millions of goroutines this way. Channel ownership is tricky to get right. And so on. Channels seem trivial on the surface, but they aren't. They look like Unix pipes, but they aren't. (That only one party to the communication can close a channelI consider to be a wart. Trying to close a closed channel panics.)
The reason we see people abusing Go channels like this is simple -- channels are generic and support type-safe type matching (with select{}). They sound like a perfect match for certain things. But they really aren't. Channels are really a great argument for why Go could benefit from generics.
[1] https://www.reddit.com/r/golang/comments/6q4p1j/comment/dkv6u8v https://www.reddit.com/r/golang/comments/6q4p1j/comment/dkv6...
[2] https://www.reddit.com/r/golang/comments/2gecvq/netchan_go_channels_over_a_network/ckix68f/ https://www.reddit.com/r/golang/comments/2gecvq/netchan_go_c...
- MoOmer 9y agoOn the other hand, I use channels successfully for queuing and processing data processing pipelines in many data ingestion applications. There are patterns that work well, and appropriate use of the context package, error receiver channels, and sanity work very well for some problems.