Idiomatic Go on Atharva Pandey

Lesson 10: Zero Values Are Useful — Go types that work before you touch them

Mon, 09 Mar 2026 00:00:00 +0000

In most languages, a freshly declared variable is either uninitialized garbage you can’t touch safely, or it needs a constructor call before it does anything useful. Go takes a different approach: every variable always has a value. When you don’t provide one, Go assigns the zero value for the type. What makes this interesting is that Go’s standard library is full of types designed so that their zero value is immediately useful — no constructor required.

Lesson 12: Value vs Pointer Receivers — The method that silently does nothing

Mon, 23 Feb 2026 00:00:00 +0000

Value vs pointer receivers is one of those topics that seems like a style preference until it silently breaks your program. The tell is a method that looks like it mutates a struct, compiles without complaint, but the mutations simply don’t persist. You add a log line, the value is right inside the method — and wrong the moment the method returns.

The Problem

A value receiver operates on a copy. Every time you call the method, Go copies the entire struct and passes the copy to the method. Mutations happen on the copy, which gets discarded when the method returns. The original is untouched.

Lesson 19: Table-Driven Tests — One test function, fifty test cases

Mon, 09 Feb 2026 00:00:00 +0000

Most engineers know to write tests. Fewer think about how the test code itself should scale. When you need to cover thirty input variations of a function, duplicating the test body thirty times produces something that’s painful to read, painful to extend, and painful to debug when it fails. Table-driven tests are the pattern that scales. A slice of cases, one loop — your test code stays as clean as your production code.

Lesson 22: Small Packages Win — One package, one job

Mon, 26 Jan 2026 00:00:00 +0000

There is a particular kind of Go codebase that’s immediately recognizable as written by someone still thinking in another language. It has a utils package. Maybe a common package. Possibly a helpers folder with a file called misc.go. Every function that doesn’t obviously belong somewhere ends up there, and over time these packages become the junk drawers of the codebase — bloated, unfocused, and imported by everything.

Go has a better way. Small packages with narrow responsibilities. One package, one idea.

Lesson 7: Slices Are Views, Not Arrays — Mutations you didn''t ask for

Mon, 12 Jan 2026 00:00:00 +0000

If you’re coming from Python, JavaScript, or Java, slices look familiar enough that you’ll assume you understand them. That assumption will hold right up until something mutates data you didn’t expect to be mutable, or a change you made inside a function mysteriously doesn’t show up outside it. Both surprises have the same root cause: a slice is not a copy of its data, it’s a window into an underlying array that may be shared with other slices.

Lesson 25: Simplicity Is a Language Feature — Why Go says no so you can ship

Mon, 29 Dec 2025 00:00:00 +0000

Every Go design decision that looks like a missing feature is actually a deliberate choice to remove cognitive overhead. No method overloading. No implicit conversions. One canonical formatter. Generics that arrived late and deliberately. Go’s simplicity is not an accident — it’s a feature, and one that pays compounding dividends as a codebase and team grow.

The Problem

Languages that offer maximum expressiveness also offer maximum inconsistency. In Java or C++, method overloading sounds convenient:

Lesson 17: select Is Elegant — Waiting on multiple futures without blocking

Mon, 15 Dec 2025 00:00:00 +0000

Every non-trivial concurrent program eventually needs to wait on more than one thing at a time. Maybe you’re waiting on a job channel but also need to respond to cancellation. Maybe you want to fetch from a channel but bail out after a timeout. Sequential channel receives can’t do this — they block on one thing and miss everything else. select is the solution, and it’s more powerful than it looks.

Lesson 9: range Gotchas — The loop variable that bit every Go team

Mon, 01 Dec 2025 00:00:00 +0000

range looks harmless. Index and value, loop over a slice — what could go wrong? Quite a bit, it turns out. Some of the most insidious bugs I’ve seen in Go codebases come from assumptions about range that seem obvious but are wrong. One was painful enough that Go 1.22 changed the fundamental loop semantics to fix it. Let’s walk through each gotcha and the correct pattern to use.

The Problem

The classic range bug — the one that famously broke production code at teams large and small for years — is the loop variable capture problem. In Go versions before 1.22, every iteration of a range loop reused the same loop variable. Taking its address multiple times gave you the same address every time.

Lesson 24: Prefer Plain Structs — Boring code is correct code

Mon, 17 Nov 2025 00:00:00 +0000

There is a particular brand of cleverness that feels deeply satisfying to write and deeply painful to maintain. The AbstractServiceProviderFactory. The builder that returns a builder that configures a builder. The generic interface so abstract it could model anything and therefore models nothing well. Go’s culture pushes back hard against this tendency, and for good reason: I’ve seen more bugs traced to abstraction layers than to simple structs.

The Problem

The most common form of over-engineering in Go is attempting to import Java-style construction patterns. Go doesn’t have constructors, so engineers invent them — and the result is code that’s harder to configure, not easier:

Lesson 11: Nil Slice vs Empty Slice — Same length, different meaning

Mon, 03 Nov 2025 00:00:00 +0000

Go has two ways to have a slice with zero elements, and they are not the same thing. Developers coming from Python, Ruby, or JavaScript expect an empty collection to just be an empty collection. In Go, the distinction between a nil slice and an empty slice is subtle enough that you can miss it for months — right up until a frontend engineer files a bug because your API is returning null instead of [].

Lesson 18: sync.Mutex Is Often Simpler — Not everything needs a channel

Mon, 20 Oct 2025 00:00:00 +0000

After you absorb the Go concurrency philosophy — share memory by communicating — there’s a temptation to reach for channels every time two goroutines need to share data. Resist that. Channels are for coordination and ownership transfer. For shared mutable state that multiple goroutines read and write, a mutex is usually clearer, simpler, and faster. Using a channel where a mutex belongs is one of those things that looks idiomatic but isn’t.

Lesson 3: Multiple Return Values — Go functions don't hide their failures

Mon, 06 Oct 2025 00:00:00 +0000

In most languages, a function returns one thing and communicates failure through a side channel — an exception, a null, a magic sentinel value. Go’s approach is different: functions can return multiple values, and the convention is to use that to make failure explicit in the signature itself. Once you’ve used it for a while, hiding failures in side channels starts to feel dishonest.

The Problem

Sentinel values are the old-school way to signal failure from a function. You pick some value that “shouldn’t” appear in normal results and treat it as an error signal:

Lesson 13: iota for Enums — Constants that count themselves

Mon, 22 Sep 2025 00:00:00 +0000

Go doesn’t have a built-in enum keyword. What it has is iota, a constant counter that resets to zero at the start of each const block and increments with every constant declaration. It sounds underwhelming. In practice it gives you typed enums, bitmask permissions, and self-maintaining constant sequences — all without any runtime overhead.

The Problem

The naive approach to enums in Go is plain integer constants or string constants. Both work, but neither gives you type safety:

Lesson 20: internal Package Is Underrated — Compiler-enforced privacy for free

Mon, 08 Sep 2025 00:00:00 +0000

Go has two visibility levels: exported (starts with a capital letter) and unexported (doesn’t). Most engineers use only these two. But there’s a third option that the language gives you for free, and it’s more useful than most people realize. The internal directory enforces that certain packages can only be imported by code within your own module — and the compiler, not documentation or convention, does the enforcing.

Exported symbols are API commitments. Once something is exported and external code is depending on it, changing it is a breaking change. The internal package is the escape hatch: share code across multiple packages in your own codebase without accidentally publishing an API surface you’ll have to maintain forever.

Lesson 5: Implicit Interfaces — The best decoupling you'll never declare

Mon, 25 Aug 2025 00:00:00 +0000

In Java or C#, you declare that a class implements an interface. You write implements Runnable, and the compiler ties that class to that interface forever. Go doesn’t work that way. A type satisfies an interface the moment it has the right methods — no declaration, no explicit relationship. This sounds like a minor syntactic difference, but it changes how you design systems in ways that compound over time.

The Problem

When interfaces are declared by the implementor (the Java way), you end up with a few recurring problems.

Lesson 15: Goroutines Are Cheap, Not Free — 2KB that can eat your server

Mon, 11 Aug 2025 00:00:00 +0000

“Goroutines are cheap” is something you read in every Go introduction. It’s true. A goroutine starts with a 2KB stack and the runtime handles scheduling. Spinning up a thousand of them is trivial. The part the introductions leave out is that “cheap” is not “free,” and goroutines that you start and never stop are a leak — one that doesn’t crash your program, just slowly eats your memory and degrades your scheduler until something gives.

Lesson 23: Error Values, Not Exceptions — Errors you can actually inspect

Mon, 28 Jul 2025 00:00:00 +0000

In most languages, errors are events — they get thrown, they propagate up the call stack, and you catch them somewhere above. Go rejects this model entirely. In Go, an error is a value, just like an integer or a string. You pass it around, inspect it, wrap it with context, and check it right where it happens. Ignore it and your code doesn’t crash loudly; it quietly does the wrong thing, and you’ll find out at the worst possible moment.

Lesson 1: Error Handling — Your code is lying if it ignores errors

Mon, 14 Jul 2025 00:00:00 +0000

If you’re coming from Python, Java, or JavaScript, Go’s error handling will feel strange at first. There’s no try/catch. No exceptions bubbling up the call stack. Instead, errors are just values — and you deal with them right where they happen. Ignore them and your code doesn’t crash loudly; it quietly lies to you, and you won’t find out until 2am when production is on fire.

The Problem

The blank identifier _ is the most dangerous character in Go. Here’s what it looks like when engineers first start writing Go:

Lesson 2: defer for Cleanup — Put the cleanup next to the mess

Mon, 30 Jun 2025 00:00:00 +0000

Every time you open a file, acquire a lock, or start a database transaction, you’ve created a resource that needs to be released when you’re done with it. In most languages you manage this with finally blocks or RAII patterns. Miss one cleanup and you’ve got a leak. Go has defer, and once it clicks, you’ll wonder how you ever coded without it.

The Problem

Here’s what resource cleanup looks like without defer. Real code, the kind that ships:

Lesson 14: context.Context — The parameter every function should take first

Mon, 16 Jun 2025 00:00:00 +0000

Without context.Context, a function that makes a database call, fires an HTTP request, or runs a long computation has no way to be told to stop. The caller times out, the user closes the browser tab, the load balancer kills the connection — and your function keeps running, consuming CPU and holding database connections, doing work that nobody will ever see. context.Context is how Go solves this.

The Problem

A function with no context cannot be cancelled. It runs until it finishes, or until the process dies. In an HTTP server handling hundreds of requests per second, this accumulates fast:

Lesson 21: Composition Over Inheritance — Small pieces, loosely joined

Mon, 02 Jun 2025 00:00:00 +0000

If you’ve come from Java or C++, you’re probably waiting for Go to show you its inheritance model. Where’s the extends keyword? Where are the base classes? There aren’t any — Go made a deliberate choice to leave them out. After writing a few thousand lines of Go, most people agree it was the right call.

The Problem

Object-oriented languages lean heavily on the “is-a” relationship. A Dog is-a Animal. A Manager is-a Employee. This sounds elegant until real-world complexity enters the picture: is a FlyingFish a Fish or a Bird? Now you’re in multiple inheritance territory and things get messy fast. And in Go, the instinct to fake it with named fields creates its own noise:

Lesson 4: The comma ok Idiom — Two returns that save you from panics

Mon, 19 May 2025 00:00:00 +0000

There are three places in Go where a missing second return value means your program either silently does the wrong thing or blows up entirely: reading from a map with a missing key, asserting a type on an interface, and receiving from a closed channel. The language’s answer to all three is the same — a boolean second return that tells you whether the operation actually succeeded. This is the comma-ok idiom, and you’ll use it constantly.

Lesson 16: Channels Are for Coordination — Stop using channels as fancy mutexes

Mon, 05 May 2025 00:00:00 +0000

Channels are Go’s most recognizable concurrency feature, and also one of the most misused. The moment engineers learn about them, there’s a strong temptation to reach for a channel every time two goroutines need to interact. That instinct is wrong about half the time. Channels are for coordination — signaling events, distributing work, collecting results. They are not a universal replacement for shared state.

Rob Pike’s line from his 2012 talk sums it up: “Do not communicate by sharing memory; share memory by communicating.” That’s a guiding philosophy, not an absolute rule.

Lesson 8: Capacity Matters — The allocation tax you''re paying without knowing

Mon, 21 Apr 2025 00:00:00 +0000

There’s a one-line fix that will make your hot paths faster, use less memory, and reduce GC pressure. It costs you nothing in readability. Most Go programmers know about it. Far fewer actually do it consistently. The fix is telling Go how big a slice is going to be before you start filling it.

The Problem

This is the pattern you reach for by reflex, especially if you’ve come from languages where dynamic arrays just grow as needed:

Lesson 6: Accept Interfaces, Return Structs — Flexibility in, certainty out

Mon, 07 Apr 2025 00:00:00 +0000

Here’s a mistake I see in almost every Go codebase written by people coming from Java or C#: they accept concrete types everywhere and return interfaces from constructors. It feels “enterprise-y”. It’s actually backwards. The idiomatic Go version is the opposite — accept the smallest interface that does the job, return the richest concrete type you have.

The Problem

Most of the pain comes from accepting concrete types. Once you lock a function to a specific concrete type, every caller that doesn’t have exactly that type is stuck. Tests become integration tests. Swapping implementations requires rewriting functions. And the function itself becomes harder to compose.