4 ms·

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.

mort96 1y ago
Channels haven't really changed since then, unless there was some significant evolution between 2016 and ~2018 that I don't know about. 2025 Go code that uses channels looks very similar to 2018 Go code that uses channels.
- regularfry 1y ago
  I'm also wondering about the internals though. There are a couple of places that GC and the hypothetical sufficiently-smart-compiler are called out in the article where you could think there might be improvements possible without breaking existing code.
sapiogram 1y ago
Absolutely nothing has changed at the language level, and for using channels and the `go` keyword directly, there isn't really tooling to help either. Most experienced Golang practitioners have reached the same conclusions as this blog post: Just don't use channels, even for problems that look simple. I used Go professionally for two years, and it's by far the worst thing about the language. The number of footguns is astounding.
- pdimitar 1y ago
  Okay, but what do you use then?
athoscouto 1y ago
Yes. See update 2 FTA for a 2019 study on go concurrency bugs. Most go devs that I know consider using higher level synchronization mechanisms the right way to go (pun intended). sync.WaitGroup and errgroup are two common used options.
deleted 1y ago
[deleted]
fpoling 1y ago
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.
- NBJack 1y ago
  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.
  - fpoling 1y ago
    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.
    - Mawr 1y ago
      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 https://news.ycombinator.com/item?id=39317648
      - eptcyka 1y ago
        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.

mort96 1y ago

Channels haven't really changed since then, unless there was some significant evolution between 2016 and ~2018 that I don't know about. 2025 Go code that uses channels looks very similar to 2018 Go code that uses channels.

regularfry 1y ago
I'm also wondering about the internals though. There are a couple of places that GC and the hypothetical sufficiently-smart-compiler are called out in the article where you could think there might be improvements possible without breaking existing code.

sapiogram 1y ago

Absolutely nothing has changed at the language level, and for using channels and the `go` keyword directly, there isn't really tooling to help either. Most experienced Golang practitioners have reached the same conclusions as this blog post: Just don't use channels, even for problems that look simple. I used Go professionally for two years, and it's by far the worst thing about the language. The number of footguns is astounding.

pdimitar 1y ago
Okay, but what do you use then?

athoscouto 1y ago

Yes. See update 2 FTA for a 2019 study on go concurrency bugs. Most go devs that I know consider using higher level synchronization mechanisms the right way to go (pun intended). sync.WaitGroup and errgroup are two common used options.

deleted 1y ago

[deleted]

fpoling 1y ago

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.

NBJack 1y ago
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.
- fpoling 1y ago
  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.
  - Mawr 1y ago
    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 https://news.ycombinator.com/item?id=39317648
    - eptcyka 1y ago
      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.