Go Patterns: Go design patterns and idioms library
Go Patterns is worth bookmarking as a reference table, not a book to read cover to cover. It sorts Go design patterns into ten categories and marks each one with a checkmark or an X, so you know before you click whether you're getting a runnable code sample or just a name and a one-line description. That status column is the whole value proposition here.
What is the Go Patterns collection?
Go Patterns is a GitHub repository (tmrts/go-patterns) that catalogs idiomatic design and application patterns for the Go language as a set of linked markdown files. The README groups entries into ten tables — Creational, Structural, Behavioral, Synchronization, Concurrency, Messaging, Stability, Profiling, Idioms, and Anti-Patterns — each row giving a pattern name, a one-line description, and a checkmark for whether a code example exists yet.
Design patterns covered in the collection
- ✓Ten pattern categories — creational, structural, behavioral, synchronization, concurrency, messaging, stability, profiling, idioms, and anti-patterns — each its own README section with a linked table.
- ✓A status column (✔/✘) next to every pattern marking which ones have a written code example versus which are still a name and a one-line description.
- ✓Concurrency-specific patterns most OOP pattern books skip entirely: Fan-In/Fan-Out, Bounded Parallelism, Generators, and a Reactor entry for demultiplexing service requests.
- ✓Stability patterns borrowed from distributed-systems practice — Circuit-Breaker, Bulkheads, Deadline, Fail-Fast, Handshaking, Steady-State — applied to Go services rather than the usual GoF class patterns.
- ✓A single documented anti-pattern, Cascading Failures, describing how one component's failure propagates through interconnected parts.
- ✓A Functional Options idiom page, Go's answer to constructor overloading, filed separately from the classic Creational, Structural, and Behavioral pattern groups.
When to apply each pattern category
- •Reaching for Singleton, Builder, or Factory Method when you need a controlled way to construct a type — several of the creational patterns here already have runnable code.
- •Picking a concurrency primitive — Fan-Out/Fan-In for worker pools, Bounded Parallelism for capped goroutine counts, Semaphore for limiting access to a shared resource.
- •Adding resilience to a service boundary with Circuit-Breaker before a downstream dependency starts timing out under load.
- •Structuring an API around Functional Options instead of a constructor with a dozen positional arguments.
- •Studying the unimplemented entries (Bridge, Mediator, Visitor, and others) as reading material even without code, since the description column still explains the intent.
Strengths
- ✓Every pattern list is a clickable table — category, name, one-line description, and status — so scanning the whole taxonomy takes one screen instead of a search-and-click loop.
- ✓Groups patterns Go engineers actually reach for at runtime — Semaphore, Circuit-Breaker, Fan-In/Fan-Out — under headings a Gang of Four book never uses, next to the classic Creational/Structural/Behavioral set.
- ✓The implemented entries link straight to a Go-flavored writeup instead of a generic pseudocode example.
- ✓Apache-2.0 licensed, so pulling a pattern's explanation or adapting its code sample into your own project or internal wiki isn't a licensing question.
What the collection does not cover
- △More than half the catalogued patterns are marked ✘ — a name, a one-line description, and a linked markdown file with no Go code inside it.
- △No changelog or dates anywhere in the source, so there's no way to tell how recently any given pattern page was touched.
- △Entries are pattern-by-pattern markdown files, not a single narrative — no chapter compares patterns against each other or explains when to pick one category over another.
- △The anti-patterns section covers exactly one entry, Cascading Failures, so it's not a broad catalog of Go mistakes to avoid.
Other Go design pattern resources
Frequently asked questions
Go Patterns catalogs 48 design pattern and idiom entries in total, spread across ten categories: Creational, Structural, Behavioral, Synchronization, Concurrency, Messaging, Stability, Profiling, Idioms, and Anti-Patterns. Each category gets its own table in the README, with every row linking out to a short markdown page for that specific pattern.
Of the 48 entries in the Go Patterns collection, 18 are marked with a checkmark showing a written Go code example exists for that pattern. The remaining 30 list only a name and a one-line description in the table, with the linked markdown page containing no code sample yet.
Go Patterns splits its entire catalog into ten categories: Creational, Structural, Behavioral, Synchronization, Concurrency, Messaging, Stability, Profiling, Idioms, and Anti-Patterns. Each category appears as its own table in the README, listing every pattern's name, a one-line description, and whether a Go code example has been written for it yet.
The Go Patterns README doesn't publish a changelog or per-pattern commit dates, so how recently any single page was updated can't be confirmed from the collection's own documentation. What has stayed constant is the category structure and the pattern list itself, which functions as a stable reference regardless of update cadence.
In Go Patterns, Synchronization patterns — Mutex, Semaphore, Read-Write Lock, Condition Variable — control exclusive or shared access to one resource. Concurrency patterns — Bounded Parallelism, Generators, Parallelism, Producer Consumer — structure how independent tasks get split up and run, not how they share a resource.
Go Patterns documents exactly one anti-pattern: Cascading Failures, filed under its own Anti-Patterns category. The README describes it as a failure in a system of interconnected parts, where one component failing triggers a domino effect that spreads the failure through the rest of the system.
Who should try it — and who should skip
Pick this up if you already write Go and want a name and a one-line definition for something you're about to build — a worker pool, a circuit breaker, a functional-options constructor — plus a linked example when one exists. Skip it if you're new to Go itself: the collection assumes you already read goroutines, channels, and interfaces comfortably, and it won't teach you the language. Skip it too if you want a single narrative arguing for one pattern over another — this is a reference table, not a design textbook.
Related repositories
Is go-patterns worth your time?
ChatGPT, Claude and Perplexity can all read this page. Ask one of them what it makes of go-patterns.