I've been writing Go for a while now, and somewhere along the way something shifted.
My code started feeling less like "code that happens to be in Go" and more like... Go code. Hard to explain, but you notice it when it happens.
Go has patterns. Not rules exactly, but ways of doing things that show up everywhere across the language and the ecosystem. Error handling. Naming. Control flow. The way you structure types. You start picking them up gradually, and when you finally start using them yourself, your code starts to feel right in a way that's difficult to articulate.
This article is just me sharing the ones that clicked for me. Some are well-known idioms. Some are just habits I picked up from reading enough Go code written by people who clearly knew what they were doing.
This isn’t the official take though. For that, go read Effective Go. It's from the Go team and it's genuinely good. Think of this as the stuff I wish I'd come across earlier.
Okay. Let's get into it.
1. Go Makes You Deal With Uncertainty Explicitly
One of the first things that hits you when you start writing Go is that its error handling is very explicit.
Two patterns show up everywhere, and once you understand what they're actually doing, a huge chunk of Go code starts making sense.
err != nil : the error check you'll write a thousand times
In most languages, errors get thrown and caught somewhere up the chain. Go doesn't do that. Functions that can fail return the error directly, and you check it right there.
user, err := getUserByID(id)
if err != nil {
return err
}
At first this feels repetitive. You write if err != nil so many times you start doing it in your sleep. But that's kind of the point. There's no hidden control flow. No wondering where an exception might surface. The error is right there, and you deal with it or you pass it up. It’s your call.
What makes it even nicer is redeclaration. If you're chaining multiple calls, you don't need a new err variable each time. Go lets you reuse the one err variable with := as long as at least one variable on the left is new:
user, err := getUserByID(id)
if err != nil {
return err
}
profile, err := getProfile(user.ID)
if err != nil {
return err
}
Same err, reassigned each time. You just keep going down the chain, handling as you go.
The comma-ok idiom: "does this even exist?"
The other pattern is comma-ok. You see it when reading from a map, doing a type assertion, or receiving from a channel:
value, ok := someMap[key]
if !ok {
// key doesn't exist
}
The second value, ok , is just a boolean. It's Go's way of saying: this operation might not give you anything useful, here's how you check.
It’s really the same idea as err != nil. Go doesn't like silent failures. It hands you the result and the signal that tells you whether it’s safe to use.
This has been pretty good for me, cause before Go I tended to skip error checks and just sort of assume things exist.
2. Naming Things the Go Way
Go is pretty opinionated about names. Not in a loud way, just in a "this is how we do it here" way. Two things tripped me up early on.
Package-scoped names
When I started out I was writing things like jobs.JobsService and companies.CompaniesService. Felt thorough. Felt descriptive. Also felt redundant the moment someone pointed it out to me.
The package name is already doing half the work. jobs.Service says exactly the same thing as jobs.JobsService, just without the stutter. Go leans on this everywhere. You're not writing the type in isolation, you're writing it in context. Let the package carry its weight.
Once I internalized this, I started catching myself doing it with other things too. jobs.JobFilter becoming jobs.Filter. users.UserStore becoming users.Store. Much cleaner, much simpler… don’t you think?
Interface names: Reader, Writer, and friends
This one confused me for longer than I'd like to admit.
Go's convention is to name interfaces after what they do, usually as a single word with an -er suffix. Reader. Writer. Stringer. Handler. It sounds simple but it's actually a really clean system once it clicks. If your type has a Read method, it's a Reader. That's it.
The practical payoff is standard library function signatures become much easier to read and understand. When you see a function that accepts an io.Writer, you immediately know: anything with a Write method works here. os.File, bytes.Buffer, http.ResponseWriter. They all qualify.
3. Writing Clean Control Flow
This section is about the stuff that makes Go code easy to read top to bottom. The patterns here are some of my favorite, even though they’re much more convenience type patterns than patterns that have a lot to do with whether your program runs correctly.
Early returns instead of if-else chains
I used to write a lot of this:
if condition {
// do thing
} else if other condition {
// do other thing
} else {
// fallback
}
Go developers tend to flip that around. Handle the bad cases first, return early, and let the happy path sit at the bottom with no indentation:
if !condition {
return err
}
if !otherCondition {
return err
}
// happy path here
It’s a small shift, but one that I think makes a big difference. With this pattern, you don’t need to mentally track multiple branches. You just read down.
Chaining calls with redeclaration
This one I use constantly. We already mentioned it a little. When you're making multiple calls that can fail, you don't need a fresh err variable each time. Go lets you reuse it with := as long as at least one variable on the left side is new:
user, err := getUserByID(id)
if err != nil {
return err
}
profile, err := getProfile(user.ID)
if err != nil {
return err
}
posts, err := getPostsByUser(user.ID)
if err != nil {
return err
}
Same err the whole way down. It keeps things clean and you're never managing a bunch of err1, err2, err3
Only take what you need from a range loop
If you're ranging over a slice and you only need the index, you don't have to assign the value at all:
for i := range someSlice {
// just the index
}
No need for the _ placeholder.
4. Working With Types Intentionally
Go's type system is one of the things I've come to genuinely appreciate. It nudges you toward writing code that's flexible but safe.
Interfaces for swappability
An interface in Go is just a contract. If your type has these methods, it satisfies the interface. That's it.
The reason this matters practically is swappability. Say you have a service that depends on a repository. If that repository is a concrete type, you're locked in. If you want to, for example, swap it out in tests, you can’t easily do that. Not without a refactor. But if you depend on an interface instead:
type UserRepository interface {
GetByID(id int) (User, error)
Create(u User) error
}
Now anything that implements those methods works. Your real database repository. A mock for tests. Whatever.
I use this pattern constantly in my projects now. It keeps things separate in a way that actually helps when things get complicated.
Small pure functions, orchestrated by bigger ones
Not exclusively a Go thing. More a general organizational pattern, but I’ve been doing it a lot in Go.
The idea is simple. Write small functions that do one thing and don't touch anything outside themselves. Then write a bigger function whose only job is calling those smaller ones in the right order.
func processJob(job Job) error {
if err := validateJob(job); err != nil {
return err
}
normalized := normalizeJob(job)
if err := saveJob(normalized); err != nil {
return err
}
return nil
}
validateJob, normalizeJob, saveJob , each one does its thing. processJob just calls and organizes them. When something breaks, you know exactly where to look.
make for slices when you know the size
If you know upfront how many elements a slice will have, initialize it with make:
results := make([]Job, len(input))
for i, item := range input {
results[i] = process(item)
}
Without make, you'd have to append each element, and you lose the ability to assign by index directly.
Embedding
Honestly, I don’t use this one that often. But when I do come across the need, it’s very useful.
Embedding lets one struct inherit the fields and methods of another by simply listing it in the inheriting struct:
type Animal struct {
Name string
}
func (a Animal) Speak() string {
return a.Name + " makes a sound"
}
type Dog struct {
Animal
Breed string
}
Dog gets Speak() for free
5. Concurrency: Getting a Response Back
Go's concurrency model is one of its best features. Goroutines are cheap, channels are elegant, and the whole thing just makes sense once it clicks. Most of the time when you spin up a goroutine you're firing something off and not waiting for a response. But sometimes you need one.
The pattern I've used for this is adding a result channel directly to the struct:
type Client struct {
conn net.Conn
msgCh chan string
resultCh chan error
}
When the goroutine finishes its work, it sends the result down resultCh. The caller is sitting on the other end waiting for it:
go client.handleMessage(msg)
if err := <-client.resultCh; err != nil {
log.Println("something went wrong:", err)
}
I ran into this pattern building a netcat group chat app. Multiple clients, concurrent connections, and I needed to know when something failed. Passing the result channel on the struct kept everything organized without having to thread channels through every function signature.
Wrapping Up
Here's the thing about idiomatic Go. Nobody sits down and studies it all at once. You pick it up gradually. You read someone else's code and think "oh, that's a cleaner way to do that." You get a review comment. You break something and figure out why. Slowly your code starts looking more like the language it's written in.
The patterns in this article are just the ones that stuck for me. Error handling that forces you to be explicit. Naming that lets the package do the talking. Control flow that reads like a straight line. Types that stay flexible without getting complicated.
None of it is revolutionary. That's kind of the point. Go is not a revolutionary language. It's a deliberate one. And the more you write it, the more you realize that the "boring" choices are usually the right ones.
If you want the proper, structured breakdown of idiomatic Go, go read Effective Go. It's from the people who built the language. This was just me passing on the stuff I wish I'd had earlier.
Now go write some Go. You'll figure the rest out.
