4 ms·

It took me a loooong time to fully wrap my head around channels. They’re definitely not explicit and full of subtle yet devastating bugs when used inappropriate

It took me a loooong time to fully wrap my head around channels. They’re definitely not explicit and full of subtle yet devastating bugs when used inappropriately (which is all to easy to do too). Some of the boilerplate code around using them is just ugly too. That said, there are occasions when channels have proven invaluable. I think the real issue is they were branded as a killer feature but in reality their usefulness is a little more niche than a mutex.

elithrar 5y ago
> I think the real issue is they were branded as a killer feature but in reality their usefulness is a little more niche than a mutex. Agree - and many people are surprised to learn both: a) how fast mutex ops are in practice, and b) how channels use mutexes under the covers.
- tapirl 5y ago
  Mutexes and channels really overlap in some functionalities, but not totally overlap, okay?
chakkepolja 5y ago
Correct me if I am wrong, isn't a channel basically same as blocking queues in Java? I know go but not much advanced.
- eitland 5y ago
  Seems like there are a few differences but nothing I personally would leave normal indexing, kind of working generics, Maven and a choice of 3 world class IDEs behind for: https://stackoverflow.com/questions/10690403/go-channel-vs-java-blockingqueue https://stackoverflow.com/questions/10690403/go-channel-vs-j... To each their own though. I hear a lot of people prefer it.
- clipradiowallet 5y ago
  I don't code Java, but I have the same sentiment about channels in golang to queue's in python.
- boyter 5y ago
  More or less, but with the ability to "poison" them by closing which causes downstream go-routines to exit. You can do the same thing in java by checking for a poison object and then terminate your loop. The close is built into the language itself which is useful, along with the other built in language functionality. I wrote about it here, with an example of how to do it https://boyter.org/posts/file-read-challange/ https://boyter.org/posts/file-read-challange/
  - chakkepolja 5y ago
    Thanks!
HeyImAlex 5y ago
They could have been a much more powerful primitive, but not having generics means tons of boilerplate; all basic channel patterns involve a lot of copy pasting.
- jasonwatkinspdx 5y ago
  Once generics have been out there for a while and the patterns of use in the community are clear/stable, I think there's a decent chance they'll revisit channels to help clean that up. It certainly is frustrating.
slaymaker1907 5y ago
The killer feature over a mutex, in my opinion, is that mutexes encourage sharing by default which is terrible for both program correctness and performance.
- laumars 5y ago
  That depends massively on the kind of problems you’re trying to solve. I’ve written some software where channels were the right tool, and others where mutexes were the correct choice.
fpoling 5y ago
Channels in Go lack priority support which made them unusable to express some patterns. Fortunately one can code a replacement for channels in Go using mutexes and semaphores. And that exercise in turn allows one to see that in many cases the channels are just a bad model. Things like having a single polymorphic priority message queue per go routine suits many cases better than dealing with multiple channels. And this has been known since nineties if not eighties when Ada had to add mutexes after early designs based purely on channels. So it is puzzling why Go made channels such a central feature when the priority queue just works judging by Erlang or many successful C/C++ libraries.
tapirl 5y ago
You should not blame Go channels for your inexperience of using them.
catlifeonmars 5y ago
This is a shame, because if done correctly, “share memory by communicating” eliminates a whole class of bugs. I agree that the ergonomics of Go channels leave a lot to be desired. Also, channels are still a primitive: you still need to build abstractions to do anything nontrivially useful with them. I think something like a good coroutine abstraction, or thread nursery abstraction would be ideal.

elithrar 5y ago

> I think the real issue is they were branded as a killer feature but in reality their usefulness is a little more niche than a mutex. Agree - and many people are surprised to learn both: a) how fast mutex ops are in practice, and b) how channels use mutexes under the covers.

tapirl 5y ago
Mutexes and channels really overlap in some functionalities, but not totally overlap, okay?

chakkepolja 5y ago

Correct me if I am wrong, isn't a channel basically same as blocking queues in Java? I know go but not much advanced.

eitland 5y ago
Seems like there are a few differences but nothing I personally would leave normal indexing, kind of working generics, Maven and a choice of 3 world class IDEs behind for: https://stackoverflow.com/questions/10690403/go-channel-vs-java-blockingqueue https://stackoverflow.com/questions/10690403/go-channel-vs-j... To each their own though. I hear a lot of people prefer it.
clipradiowallet 5y ago
I don't code Java, but I have the same sentiment about channels in golang to queue's in python.
boyter 5y ago
More or less, but with the ability to "poison" them by closing which causes downstream go-routines to exit. You can do the same thing in java by checking for a poison object and then terminate your loop. The close is built into the language itself which is useful, along with the other built in language functionality. I wrote about it here, with an example of how to do it https://boyter.org/posts/file-read-challange/ https://boyter.org/posts/file-read-challange/
- chakkepolja 5y ago
  Thanks!

HeyImAlex 5y ago

They could have been a much more powerful primitive, but not having generics means tons of boilerplate; all basic channel patterns involve a lot of copy pasting.

jasonwatkinspdx 5y ago
Once generics have been out there for a while and the patterns of use in the community are clear/stable, I think there's a decent chance they'll revisit channels to help clean that up. It certainly is frustrating.

slaymaker1907 5y ago

The killer feature over a mutex, in my opinion, is that mutexes encourage sharing by default which is terrible for both program correctness and performance.

laumars 5y ago
That depends massively on the kind of problems you’re trying to solve. I’ve written some software where channels were the right tool, and others where mutexes were the correct choice.

fpoling 5y ago

Channels in Go lack priority support which made them unusable to express some patterns. Fortunately one can code a replacement for channels in Go using mutexes and semaphores. And that exercise in turn allows one to see that in many cases the channels are just a bad model. Things like having a single polymorphic priority message queue per go routine suits many cases better than dealing with multiple channels. And this has been known since nineties if not eighties when Ada had to add mutexes after early designs based purely on channels. So it is puzzling why Go made channels such a central feature when the priority queue just works judging by Erlang or many successful C/C++ libraries.

tapirl 5y ago

You should not blame Go channels for your inexperience of using them.

catlifeonmars 5y ago

This is a shame, because if done correctly, “share memory by communicating” eliminates a whole class of bugs. I agree that the ergonomics of Go channels leave a lot to be desired. Also, channels are still a primitive: you still need to build abstractions to do anything nontrivially useful with them. I think something like a good coroutine abstraction, or thread nursery abstraction would be ideal.