Idioms

Let’s be honest, most of the code you write in your career will be spent reading other people’s. The good news? With Go, you’re often reading the best code—the standard library. It’s our collective textbook, written by masters of the craft. Studying it isn’t just recommended; it’s a shortcut to writing idiomatic Go yourself. Let’s crack it open. The io.Reader and io.Writer Interfaces: The Universal Adapters If you learn one thing from the standard library, let it be the power of these two interfaces. They are the duct tape and WD-40 of Go, connecting everything without anyone needing to know what “everything” is.

Right, let’s talk about one of the most quietly contentious design decisions you’ll make in a Go API: how you tell the user, “Hey, something went wrong.” You’ve got two main schools of thought. One is the classic, almost medieval approach of using sentinel errors (ErrSomethingWentWrong). The other is the more modern, pattern-matching-friendly approach of sentinel-free, opaque errors. One isn’t inherently better than the other; they solve different problems. Picking the wrong one for the job is how you build an API that feels like a rusty bear trap for the poor soul trying to use it.

Right, so you want to do dependency injection but you don’t want to pull in some 50-megabyte framework that requires an XML configuration file written in ancient Sumerian. Good. Neither do I. Dependency injection isn’t a framework feature; it’s a design pattern, a way of structuring your code so it doesn’t turn into an un-testable, un-maintainable hairball. The core idea is painfully simple: don’t create your dependencies inside a struct; accept them as parameters. That’s it. You’ve just understood the secret. The rest is just us applying that one rule with varying levels of elegance and ceremony.

Right, let’s talk about Hexagonal Architecture. Forget the fancy name for a second; at its core, it’s a shockingly sane idea: your business logic shouldn’t give a damn about your database, your web framework, or whether your HTTP requests come in via carrier pigeon. It’s about drawing a hard, enforceable line between the what of your application (the domain logic, the juicy bits that make you money) and the how (the boring, often-changing plumbing of databases, APIs, and UIs).

Look, let’s get one thing straight: Domain-Driven Design isn’t a library you import. You can’t go get it. It’s a way of thinking, a set of principles for taming complexity. And in Go, which prizes simplicity and pragmatism above all else, applying DDD is less about rigidly following every pattern from the book and more about stealing the good ideas and adapting them to fit the language’s ethos. We’re going to focus on the concepts that give you the most bang for your buck without turning your code into an abstract factory factory.

Right, let’s talk about the Repository pattern. You’ve probably heard of it. It’s the one that’s supposed to save you from the database, acting as a persistent in-memory collection. In Go, its implementation is a beautiful study in pragmatism, where we take a fancy academic pattern and bash it against the rocks of reality until it works for us, not against us. The core idea is simple: you want to decouple your core business logic (the stuff that makes you money) from the nitty-gritty details of how you shove data into a storage system (the stuff that gives you migraines). Your UserService shouldn’t care if its data comes from PostgreSQL, a giant CSV file, or a psychic octopus. The Repository is the mediator. It speaks in terms of your domain objects (User, Order) and translates those into the crude language of SELECT * FROM... or collection.Find().

Right, let’s talk about one of the most embarrassingly simple yet profoundly powerful ideas in software design: table-driven development. You’ve probably written a function with a gnarly switch or a chain of if/else if statements that made you feel a little dirty afterward. You know the type: func GetSound(animal string) string { if animal == "dog" { return "woof" } else if animal == "cat" { return "meow" } else if animal == "cow" { return "moo" } else if animal == "duck" { return "quack" } // ... and so on for 20 more animals return "what did you just call me?" } This code is verbose, brittle, and a pain to test or extend. It screams “I was written at 4:55 PM on a Friday.” The table-driven approach looks at this mess and asks a better question: “What if the data was the code?”

Let’s talk about one of the most quietly powerful, “if you know, you know” principles in Go: accept interfaces, return structs. It sounds like a bumper sticker, but it’s the secret handshake that separates pleasant-to-use libraries from ones that feel like they’re actively fighting you. The core idea is beautifully simple. Your functions and methods should be liberal in what they accept—ask for the smallest possible interface that gets the job done. But they should be conservative in what they return—give the user the concrete, most useful type you can. This maximizes flexibility for the caller and minimizes confusion about what they’re getting back.

Let’s be honest: you’ve been tempted. You see a function that takes a string and returns an int, and a little voice in your head whispers, “What if we need to handle other types later? We should make this generic now.” That voice is your inner architect, and while its intentions are noble, it’s often your enemy. In Go, the most powerful design tool is often the concrete type, and the most common design mistake is abandoning it too soon in favor of needless abstraction.

Right, let’s talk about table-driven design. You’ve probably already used this pattern without knowing its fancy name. It’s the moment you realize you’re about to write your fifth if or case statement for what is essentially the same operation, just on different data, and you scream “there has to be a better way!” There is. It’s called table-driven design, and it’s embarrassingly simple. Instead of a sprawling chain of conditional logic, you define your behavior in a data structure—a table—and then you write one, single, elegant loop to process it. The logic is decoupled from the data, which means your code becomes more readable, more testable, and infinitely easier to change and extend. It’s the difference between hand-carving each piece of a model and using a 3D printer. One is artisanally painful; the other is brilliantly efficient.

Right, let’s talk about errgroup. You’ve been there: you have a handful of goroutines doing work, and you need to wait for them all to finish, but if any of them fails, you want to cancel the whole operation immediately. You could roll this yourself with a sync.WaitGroup, some channels, and a context.Context for cancellation, but you’d be writing the same boilerplate for the tenth time this week. Stop that. The fine folks at the Go team felt your pain and gave us golang.org/x/sync/errgroup. It’s essentially a WaitGroup that understands errors and context.

Right, let’s talk about semaphores. You’ve probably heard the term in operating systems or concurrent programming—it’s a fancy word for a counter that controls access to a finite number of resources. In Go, we don’t have a semaphore package in the standard library. Why? Because we can build a perfectly good one, a weighted one at that, in about three lines of code using a buffered channel. It’s one of those elegant “less is more” designs that makes you appreciate Go’s simplicity, even if you occasionally want to throw your keyboard at it.

Right, the Worker Pool pattern. You’ve hit that beautiful moment in your Go journey where you realize that just slapping a go keyword in front of every function call is a fantastic way to trigger a cascading failure, get rate-limited into the next decade, or simply melt your machine’s CPU. Congratulations! Welcome to the big leagues, where we think about bounding our concurrency instead of just unleashing it like a herd of cats.

Right, let’s talk about the pipeline pattern. You’ve probably got some data that needs a series of operations performed on it: fetch it, process it, filter it, transform it, store it. You could write one big, gnarly function that does all of that. But then you’d have a monster that’s impossible to test, reason about, or modify without breaking three other things. We’re better than that. The pipeline pattern is our escape hatch. We break that big process into discrete stages, each a separate goroutine, connected by channels. Data flows in one end, gets worked on, and flows out the other. It’s like an assembly line for your data, and it’s one of the most elegant ways to structure concurrent programs in Go. It makes your code modular, testable, and frankly, a joy to work with.

Right, let’s settle this. You’re about to configure a thing in Go—a server, a client, a database connection, some complex monstrosity you built. You quickly realize your constructor function is getting out of hand. It’s starting to look like NewThing(host string, port int, timeout time.Duration, enableLogging bool, maxRetries int, name string, fluxCapacitorCapacity float64) and it’s an unreadable, unmaintainable mess. You need a pattern. You’ve likely seen two: the Options Struct and Functional Options. Let’s break down why both exist and when to use which.

Let’s be honest: you’ve seen this before. You’re trying to create a Thing, and its constructor is a nightmare. You either have a function with fourteen arguments where the last nine are almost always the same, or you’ve got a dozen different NewThingWithXAndYButNotZ constructors. It’s a mess. It’s un-Go-like. It’s exactly the kind of ceremony we’re trying to avoid. Enter the Functional Options pattern. This is one of those patterns that looks like magic the first time you see it, but once you understand it, you’ll wonder how you ever lived without it. The core idea is simple: we pass a variadic slice of functions to our constructor, and each function operates on the struct we’re building. It’s configuration with a functional flair.