←back to thread

Problems with Go channels (2016)

(www.jtolio.com)
159 points mpweiher | 2 comments | 13 Apr 25 05:43 UTC | HN request time: 0.404s | source
Show context
regularfry ◴[13 Apr 25 11:56 UTC] No.43672109[source]▶
This was 2016. Is it all still true? I know things will be backwards compatible, but I haven't kept track of what else has made it into the toolbox since then.
replies(5): >>43672204 #>>43672264 #>>43672270 #>>43672320 #>>43672419 #
fpoling ◴[13 Apr 25 12:50 UTC] No.43672419[source]▶
The only thing that changed was Context and its support in networking and other libraries to do asynchronous cancellation. It made managing network connections with channels somewhat easier.

But in general the conclusion still stands. Channels brings unnecessarily complexity. In practice message passing with one queue per goroutine and support for priority message delivery (which one cannot implement with channels) gives better designs with less issues.

replies(1): >>43672810 #
NBJack ◴[13 Apr 25 13:53 UTC] No.43672810[source]▶
My hot take on context is that it's secretly an anti-pattern used only because of resistance to thread locals. While I understand the desire to avoid spooky action at a distance, the fact that I have to include it in every function signature I could possibly use it in is just a bit exhausting. Given I could inadvertently spin up a new one at will also makes me a bit uneasy.
replies(1): >>43673105 #
fpoling ◴[13 Apr 25 14:34 UTC] No.43673105[source]▶
One of the often mentioned advantages of Go thread model is that it does not color functions allowing any code to start a goroutine. But with Context needed for any code that can block that advantage is lost with ctx argument being the color.
replies(2): >>43673322 #>>43673483 #
Mawr ◴[13 Apr 25 15:05 UTC] No.43673322[source]▶
Function arguments do not color functions. If you'd like to call a function that takes a Context argument without it, just pass in a context.Background(). It's a non-issue.

Full rebuttal by jerf here: https://news.ycombinator.com/item?id=39317648

replies(2): >>43674351 #>>43676774 #
eptcyka ◴[13 Apr 25 17:27 UTC] No.43674351[source]▶
Coloring is a non-issue, context itself is. Newcomers find it unintuitive, and implementing a cancellable piece of work is incredibly cumbersome. One can only cancel a read/write to a channel, implementing cancellation implies a 3 line increase to every channel operation, cancelling blocking I/O defers to the catchphrase that utilises the name of the language itself.
replies(1): >>43675001 #
1. fpoling ◴[13 Apr 25 18:58 UTC] No.43675001[source]▶
Cancelling blocking IO is such a pain point in Go indeed. One can do it via careful Close() calls from another goroutine while ensuring that close is called only once. But Go provides absolutely no help for that in the standard library.
replies(1): >>43683423 #
2. dfawcus ◴[14 Apr 25 17:02 UTC] No.43683423[source]▶
I had a need for that, on TCP and UDP connections. The former behind a net.Conn.

Rather than fiddle with Close() calls, from memory what I found worked was setting a short (or in the past) deadline on the Conn (SetReadDeadline). This as it is documented as applying even to an existing blocked call, and makes that blocked call eventually return an error.

So when I wanted to tear down the TCP connection and clean up the various goroutines associated with using the connection, I'd unblock any blocking i/o, then eventually one had an easy Close() call on the connection.

UDP was simpler, as each i/o operation had a short timeout. I've not investigated what could be done for pipe and fifo i/o.