Concurrency on A Blog for the Uninitialized

Using the "done" channel in Go

Fri, 27 Feb 2026 14:29:51 -0800

I wanted to document how a done channel is most commonly used.

Mainly because I’ve personally found it to be more confusing than it should be.

It usually looks a bit like this, when following a worker pattern:

func main() {
 var doneCh = make(chan struct{})

 // Perform some concurrent work
 // ...

 // Wait on that work
 for i := 0; i < 10; i++ {
 <-doneCh
 }
 
 // complete
}

I intentially left out a bit here to highlight what a “done” channel actually looks like.

The Worker Pattern

Thu, 26 Feb 2026 16:09:17 -0800

I really like using a worker pattern with unbuffered channels.

API calls, especially when each can be handled separately and independently, are easily implemented with this pattern, and I’ve seen it help tremendously when downloading artifacts for building in CI, for example.

Instead of setting up a buffered channel with a capacity of 10 in an attempt to concurrently handle 10 requests, you can create an unbuffered channel and read from it using 10 workers.

Golang's unbuffered and buffered channels

Wed, 25 Feb 2026 16:40:18 -0800

From the official Go Blog:

Do not communicate by sharing memory; instead, share memory by communicating.

They’re awesome because they enable concurrency support “out of the box”.

They’re basically their own type that implements concurrent safe logic of sharing memory locations of data without the explicit usage of mutexes or locks. The example in the blog link above has some code blocks that show this quite well, actually.

They can be buffered or unbuffered.