Go Memory Model & Internals on Atharva Pandey

Lesson 8: String Internals — Immutable, backed by bytes, cheaper than you think

Tue, 15 Apr 2025 00:00:00 +0000

I used to reach for []byte over string in performance-sensitive code, assuming strings were somehow more expensive because “immutability must cost something.” That intuition was wrong. Understanding what a string actually is — a read-only slice header — corrected my assumptions and simplified a lot of code I had unnecessarily complicated.

The Problem

Strings in Go are everywhere, and most developers use them without thinking about what they are at the memory level. This leads to a few common mistakes:

Lesson 7: Values Copy vs Share — When Go copies and when it doesn't

Sat, 01 Mar 2025 00:00:00 +0000

Early in my Go career I had a bug where I modified a slice inside a function expecting the caller’s slice to remain unchanged — and it did. Then I had a different bug where I expected the opposite and the caller’s slice was modified. I had no mental model for predicting which would happen. Building that model is what this lesson is about.

The Problem

Go passes everything by value. That’s the official line, and it’s true. But “by value” means different things for different types:

Lesson 6: Memory Alignment and Struct Padding — Field order affects struct size

Wed, 08 Jan 2025 00:00:00 +0000

I once reviewed a PR where someone had defined a struct with a bool field between two int64 fields, resulting in a 24-byte struct instead of the 17 bytes you might naively calculate. When I pointed it out, the response was “the compiler should handle that.” It doesn’t. Go respects the field order you give it, and it inserts padding to satisfy alignment requirements. Knowing the rules means you write efficient structs by default.

Lesson 5: GC Behavior and Tuning — GOGC and GOMEMLIMIT changed the game

Fri, 15 Nov 2024 00:00:00 +0000

For years, tuning Go’s GC meant tweaking GOGC and hoping for the best. I operated on vibes and guesswork. Then Go 1.19 introduced GOMEMLIMIT — a hard memory limit that fundamentally changed how I reason about GC tuning. Suddenly I had a second axis of control that actually matched how production memory is constrained. This lesson is the mental model I wish I had from day one.

The Problem

Go uses a concurrent, tri-color mark-and-sweep garbage collector. “Concurrent” means most of the GC work happens while your program is running, not in stop-the-world pauses. This is generally excellent, but the GC needs to be triggered somehow, and the default trigger can be surprising.

Lesson 4: Escape Analysis Deep Dive — The compiler decides where your data lives

Sat, 05 Oct 2024 00:00:00 +0000

I used to assume that every time I wrote &someStruct{} or returned a pointer from a function, I was creating a heap allocation. I was wrong — and the wrongness mattered for how I was designing APIs. After learning about escape analysis, I stopped guessing and started asking the compiler directly. This changed how I write Go.

The Problem

Go has two places to put data: the stack and the heap. Stack allocations are cheap — they’re just a pointer bump, and the stack frame is reclaimed automatically when the function returns. Heap allocations go through the memory allocator, require garbage collection, and have non-trivial overhead.

Lesson 3: Method Sets and Addressability — Why your value can't satisfy that interface

Sun, 25 Aug 2024 00:00:00 +0000

I spent a solid twenty minutes staring at a compilation error that read “does not implement interface (Write method has pointer receiver)” and thinking: I can see the Write method right there. What is Go complaining about? Once I understood method sets and why addressability matters, the rule became obvious — and I have never needed to look it up since.

The Problem

Go lets you define methods with either a value receiver or a pointer receiver:

Lesson 2: Nil Interface Gotchas — nil is not nil when it has a type

Thu, 18 Jul 2024 00:00:00 +0000

A few months into my first production Go service, I had a bug that cost me two hours. A function returned an error, I checked if err != nil and it passed — but then further down the stack the program panicked trying to call .Error() on a nil pointer. The function had returned a nil *MyError, not a nil error. These are not the same thing, and until you internalize why, you will hit this bug.

Lesson 1: Interface Representation — Two words that carry your abstractions

Mon, 10 Jun 2024 00:00:00 +0000

I remember the first time I hit a bug where err != nil returned true even though the function clearly returned nil. I spent forty minutes staring at perfectly reasonable-looking code before I realized I had no idea what an interface actually is at the memory level. Once I understood the two-word representation, that class of bug never confused me again.

The Problem

Go interfaces are the backbone of polymorphism in the language. You use them constantly — io.Reader, error, fmt.Stringer. But most developers treat them as magic. You assign a concrete value, you call methods, and somehow Go figures out which implementation to dispatch to at runtime.