3 ms·

> Why am I writing all this ceremony (comparatively little compared to other languages, but ceremony nonetheless) when the new, better way is coming? Whether o

> Why am I writing all this ceremony (comparatively little compared to other languages, but ceremony nonetheless) when the new, better way is coming? Whether or not the new way will be better is far from assured. I'm outing myself as a bit of a "get off my lawn" greybeard here, but as long as such a large swathe of the industry remains trapped in a permanent state of convulsion where everyone competes to build the next monument to their own cleverness, the unprecedented consistency, clarity and productivity that vanilla Go 1 provides will remain under-appreciated. There's an awful lot of sound and fury over generics and error handling. I sincerely hope that if and when something is done about it, it isn't done in a way that gives anyone a license to be clever. > "use channels, share memory by communicating" They walked back a bit from this, thankfully, and I'm seeing less and less nasty "channels for the sake of it" code these days as a result. The party line seems to be closer to "channels are good and bad, mutexes are good and bad, favour whichever is goodest" nowadays, and the larger projects I've worked on have typically been about 50/50 [1] [1]: https://github.com/golang/go/wiki/MutexOrChannel Whenever I think something is missing, I find it helpful to remind myself that Go is kind of the ultimate "80%" experience. Absolutely everything is 80% complete, from the language, to the tools, to the stdlib, it's performance relative to vanilla C... everywhere. 80%. I also think this is the secret of its success.

stubish 8y ago
Interesting about channels. I had been wondering why, despite always being touted as a core feature and reason for Go being awesome, I find them quite rare when looking at other people's code. I've only found them particularly useful for communication between goroutines on one project (filtering events, sending them to the correct workers), and the rest of the time mostly used to implement timeouts (and wishing for some syntactic sugar there, since it can be non-obvious how to to avoid leaking the timers).
- fpoling 8y ago
  Channels in Go do not allow to prioritize messages and proper support for cancelation is highly non-trivial. Both are necessary in complex software. With mutexes one can build all these things, but lack of language support for mutexes sucks.
- shabbyrobe 8y ago
  That's a really good point actually, I hadn't thought directly about this before. I've just evolved a position on it without articulating it directly: I almost never include them in my public APIs, almost never see them in the better APIs, and tend to count it as a strike against a package if I see that they're used without strong justification. I find there's a lot you have to do manually to handle them correctly and it's easy to miss details. I think they're best cordoned off behind isolated, encapsulated parts of a channel-free public interface. To walk back a tiny bit from my earlier "80%" claim, I reckon channels are probably more like 50% complete. The existence of "context.Context", itself very much half-baked, is a symptom of that. You have to think long and hard about cancellation and blocking every time you interact with them (even if you decide you don't ultimately need to), and the results, once you've (hopefully) handled all the corner cases can degenerate into a tangled mess that's hard to reason about, harder to test, and impossible to change. I like to call this kind of code "channel soup". I'd be interested to see proposals for what the 80% version of channels would look like. What we have now is a great start, but it's not great yet.

stubish 8y ago

Interesting about channels. I had been wondering why, despite always being touted as a core feature and reason for Go being awesome, I find them quite rare when looking at other people's code. I've only found them particularly useful for communication between goroutines on one project (filtering events, sending them to the correct workers), and the rest of the time mostly used to implement timeouts (and wishing for some syntactic sugar there, since it can be non-obvious how to to avoid leaking the timers).

fpoling 8y ago
Channels in Go do not allow to prioritize messages and proper support for cancelation is highly non-trivial. Both are necessary in complex software. With mutexes one can build all these things, but lack of language support for mutexes sucks.
shabbyrobe 8y ago
That's a really good point actually, I hadn't thought directly about this before. I've just evolved a position on it without articulating it directly: I almost never include them in my public APIs, almost never see them in the better APIs, and tend to count it as a strike against a package if I see that they're used without strong justification. I find there's a lot you have to do manually to handle them correctly and it's easy to miss details. I think they're best cordoned off behind isolated, encapsulated parts of a channel-free public interface. To walk back a tiny bit from my earlier "80%" claim, I reckon channels are probably more like 50% complete. The existence of "context.Context", itself very much half-baked, is a symptom of that. You have to think long and hard about cancellation and blocking every time you interact with them (even if you decide you don't ultimately need to), and the results, once you've (hopefully) handled all the corner cases can degenerate into a tangled mess that's hard to reason about, harder to test, and impossible to change. I like to call this kind of code "channel soup". I'd be interested to see proposals for what the 80% version of channels would look like. What we have now is a great start, but it's not great yet.