lotusirous/go-concurrency-patterns: 18 Runnable Go Examples, Read Before You Copy

What the eighteen directories actually give you

The repository is a catalogue, not a framework. Each numbered directory from 1-boring through 18-worker-pool holds a main.go, and the README maps every directory to a one-line description plus a Go Playground link. The topics are the ones you would expect from the canonical Go talks: goroutines, channels, generators, fan-in, timeouts, quit signals, daisy chains, a concurrent search built in four successive versions, ping-pong, subscription, bounded parallelism, context, ring buffer channels and worker pools.

The intended reader is someone who has read the Go tour and now wants to see the patterns in code they can run. The README points outward to the source material that shaped the list, including Rob Pike's talks and the Go blog posts on pipelines, cancellation and timeouts, and it collects a separate set of context links. That framing matters: the repository positions itself as a companion to those talks, so the value is in the runnable code, not in prose the repository does not contain.

How the code is organised and how data flows through it

Every example is a standalone program. The module is declared in go.mod as github.com/lotusirous/gochan with go 1.26, and the directory names are numeric prefixes rather than package paths, which is a deliberate sign that nothing here is imported by anything else. Each main.go is meant to be run on its own.

The progression is the interesting part. The early directories isolate one primitive at a time: 1-boring introduces a goroutine, 2-chan introduces a channel, 3-generator wraps a channel in a function that returns it, and 4-fanin merges several such channels into one. From there the examples compose. 5-restore-sequence deals with ordering, 6-select-timeout adds a timeout arm to a select, 7-quit-signal adds a shutdown path, and 8-daisy-chan chains goroutines together. The four google directories, 9-google1.0 through 12-google3.0, rebuild the same concurrent search four times, which is the clearest signal in the repository of what it is for: showing how a design changes as you add fan-in, timeouts and cancellation to the same problem.

16-context is the one that maps most directly onto production code, since the README describes it as showing how to use context in an HTTP client and server. 15-bounded-parallelism and 18-worker-pool cover the two ways of limiting how many goroutines run at once, and 17-ring-buffer-channel covers a buffered channel used as a fixed-size queue.

Running an example: from clone to first goroutine

There is no install step in the README, no package to fetch and no binary to build. The examples are ordinary Go programs, so the workflow is clone, change directory, run. The commands below assume Go is already installed and that go.mod declares go 1.26, so a toolchain at least that new is required.

Clone the repository and enter it:

git clone https://github.com/lotusirous/go-concurrency-patterns.git
cd go-concurrency-patterns

Run the first example, which the README describes as a hello world to goroutine:

go run ./1-boring

You should see the program print its lines and exit. To see the channel version, run the second directory:

go run ./2-chan

For the pattern most people arrive for, the worker pool, run the last directory:

go run ./18-worker-pool

The README also links a Go Playground snippet for every directory, so you can read and execute an example in the browser without cloning anything. If a directory fails to build, the first thing to check is your Go version against the go directive in go.mod rather than the example itself.

The limits: no tests, no license file, no library

The top-level entries are .gitignore, the eighteen numbered directories, README.md and go.mod. There is no LICENSE file, no test file, no CI configuration and no example that is packaged for reuse. The License field in the repository metadata is unknown, and the README does not state terms. If you plan to copy an example into a product, that is the first thing to resolve with the author, because nothing in the repository grants you anything explicitly.

The absence of tests is the second limit. These programs demonstrate behaviour, they do not assert it. A goroutine example that prints interleaved output tells you the pattern works on your machine today; it does not tell you the example is correct under the race detector, and the README never claims it has been checked that way. Run any example you intend to learn from with go run -race and read the output yourself.

The third limit is scope. The README does not cover error handling, backpressure in a real service, observability, or how any of these patterns behave under load. There are no benchmarks and no performance claims anywhere in the repository. If you need a production concurrency utility rather than a demonstration, this is the wrong repository: it will teach you the shape of a worker pool, and then you still have to write the worker pool.

Where it sits against golang.org/x/sync and the Go blog

The honest alternative depends on what you want. If you want runnable demonstrations, the Go blog series that this README links to, particularly the pipelines and cancellation post and the timeouts post, covers much of the same ground in prose with code, and it is maintained by the Go team. If you want a dependency you can call, golang.org/x/sync provides errgroup and semaphore, which are the packaged equivalents of what 15-bounded-parallelism and 18-worker-pool demonstrate by hand. The difference in approach is stark: x/sync gives you an API with a defined contract and error propagation, while this repository gives you a main.go you read and adapt, with no contract at all.

That is not a criticism of the repository. A semaphore package will not explain why a fan-in needs a quit channel, and the four google versions will. The right way to use both is in sequence: read the example here to understand the mechanism, then reach for x/sync when you want the mechanism without owning the code. If you only ever do the second step, you will recognise the pattern when it breaks in production, which is the point.

Maintenance status and what an upgrade would involve

The repository is not archived, and the last push was on 2026-08-03. There are no releases, so there is no version to pin and no changelog to read. Upgrading is therefore not a thing you do to a dependency; it is a thing you do to your own copy. If you vendor an example, you own it from that moment, including the go directive in go.mod, which currently requires go 1.26. A toolchain older than that will refuse to build the module.

Because the examples are self-contained, the upgrade cost is low and the maintenance cost is mostly zero until you copy something. The one recurring cost is drift: the README links a Playground snippet for each directory, and nothing in the repository enforces that the snippet and the file stay in sync. If you are teaching from this material, check the file rather than the link. On licensing, no LICENSE file appears in the top-level entries and the metadata records the license as unknown, so treat reuse as something to confirm in writing rather than assume.

Editorial conclusion

Use lotusirous/go-concurrency-patterns if you are learning Go's channel and context idioms and want eighteen small, self-contained programs you can run and step through, or if you are preparing material for a study group and want a ready-made list of topics. Do not adopt it as a dependency: go.mod declares module github.com/lotusirous/gochan, there are no releases, and the README never presents it as a library. Before relying on any example, verify two things yourself: read the main.go in the directory you care about rather than trusting the one-line description, and check the linked Go Playground snippet still matches the file, because the repository offers no versioning between the two. No LICENSE file appears among the top-level entries, so confirm the terms with the author before republishing any of this code inside your own project.

Frequently asked questions

Official sources

1. Issues
2. lotusirous/go-concurrency-patterns on GitHub
3. README