"Go channels are reasonably similar to Django ones"
Really? Only at a surface glance. Having used channels in both Go and in Clojure, I would say they are nothing like Django channels. The only thing they share is they are like a fifo pipe.
In Go and Clojure channels are an in-process async construct. They have nothing to do with the network at all. (There may be libraries that expose their network connections in the language as channels, but the channel itself is completely in process).
In these languages there is no 'routing' that needs to be set up. There is no 'linearisation' problem. They are first class and can be passed in and out of functions.
Also most importantly, pulling from or pushing to a channel appear to the programmer as a blocking operation, while under the hood the language inverts control to create a non-blocking situation. Send and receive on the Django channels look to be non-blocking and appear to the programmer to be non-blocking (correct me if I'm wrong, please).
Saying all this I'm not opposed to calling Django channels, channels. Channels is a generic term, and what is being done here in Django can be very much described as a channel. Just remember that they are actually very different to the "channels" as used in Go.
Really? Only at a surface glance. Having used channels in both Go and in Clojure, I would say they are nothing like Django channels. The only thing they share is they are like a fifo pipe.
In Go and Clojure channels are an in-process async construct. They have nothing to do with the network at all. (There may be libraries that expose their network connections in the language as channels, but the channel itself is completely in process).
In these languages there is no 'routing' that needs to be set up. There is no 'linearisation' problem. They are first class and can be passed in and out of functions.
Also most importantly, pulling from or pushing to a channel appear to the programmer as a blocking operation, while under the hood the language inverts control to create a non-blocking situation. Send and receive on the Django channels look to be non-blocking and appear to the programmer to be non-blocking (correct me if I'm wrong, please).
Saying all this I'm not opposed to calling Django channels, channels. Channels is a generic term, and what is being done here in Django can be very much described as a channel. Just remember that they are actually very different to the "channels" as used in Go.