When code calls http.Get, the name has to become an IP address before any request goes out. That's DNS's job. With the same setup as a Kubernetes pod, one name lookup sent 8 queries to a tiny DNS server I wrote to count them.
When customers called because an installed service wouldn't start, the pod was usually in ErrImagePull, sometimes ImagePullBackOff. At first that puzzled me.
Writing the GOMEMLIMIT post, I mentioned container memory limits often, but on the Kubernetes side I only knew requests as a floor and limits as a ceiling.
While preparing to change jobs, I repeated the same chores every week. I searched job sites, read each posting to judge the fit, and reworked my resume.
Starting a goroutine is easy. The hard part was deciding who changes the data, who finishes the work, and when a function may return.
In the previous post, total allocations stayed at 256MiB however I set GOGC and GOMEMLIMIT. Reusing short-lived buffers with sync.Pool is one way to shrink it.
I spend a good part of every day working with AI, for code and for writing. Yet I couldn't explain how the model was built, or in what order it computes an answer to what I send it.
The container limit was 1GB, yet the process was OOMKilled with an 800MB heap. Go has a garbage collector, so how did memory run out?
Put go in front of a call and it runs concurrently. So do 100,000 goroutines mean 100,000 threads? Does GOMAXPROCS=1 mean one task at a time?
Interfaces, slices, defer, embedding, context: looking back after five posts, most of the pitfalls came from two axes. One is "everything is copied"; the other is "object orientation without classes."
I thought putting a one-hour context.WithTimeout on a request meant it would wait up to an hour. It died at 30 seconds. The context made it all the way through; it just wasn't the only timer. And once I fixed the timer, the real problem turned out to be somewhere else.
A cluster resource list query was slow in internal testing, so I added indexes. Execution time dropped from 233ms to 104ms and I thought it was fixed. Then EXPLAIN ANALYZE showed rows read going from 205,000 to 200,025, barely changed. The numbers didn't add up.
It's a tool I use because I like it, yet the more I used it, the more doubt crept in. I only began to understand where that feeling came from after watching one interview.
I was already taking ctx as the first argument and passing it along. What I had never checked was whether canceling actually stops the goroutine. After stalling on that question in an interview, I went back to context from the start.
Validation was dying on timeouts. Within 30 minutes I had an answer, "it's N+1, batch it," and it was only half right. Reaching the final design took two changes of direction, and since the process taught me more than the code, I'm writing it down.
Go has no classes and no inheritance, yet it's hard to call it non-object-oriented. The official FAQ answers "Is Go an object-oriented language?" with "Yes and no." This post explains why by following what Go put where inheritance used to be.
Go dropped exceptions and filled the gap with defer and errors as values. All three take seconds to learn and keep producing traps for years. I reorganized them around one question: exactly when, and what, does each one hold on to?
The Go bugs I keep hitting come from holding something different from what I think I'm holding. A slice is a window, not data. A map doesn't guarantee addresses. A string isn't a character array. This post opens up the layout of all three.
You return a nil pointer and err != nil comes out true, because an interface value has two slots: a type and the data. From that two-slot layout to method sets, where interfaces should live, and the cost of dynamic dispatch.
Part three of the DB series, on design. The anomalies that duplication causes and the first three normal forms, denormalizing only for measured bottlenecks, and whether business logic belongs in an ORM or in stored procedures.
Part two of the DB series. ACID is what a transaction promises, isolation levels are the dial that trades isolation for speed, and Redo/Undo is how atomicity and durability survive a crash.
Following how compiled, statically typed code turns into runtime wins, using Go: memory layout, compiler optimizations, escape analysis, the GC, and the scheduler, each checked with tools.
The first post in a database series: deadlocks and livelocks, how to choose between pessimistic and optimistic locking, and an UPDATE without a WHERE that logged out every user.
Everyone had a different local CLAUDE.md, so Claude behaved differently on the same codebase. How we merged them into one file in git, slimmed it down, and turned it into a document that grows with every PR.
I installed Superpowers, agentmemory, context-mode, codebase-memory-mcp, and RTK and sorted them by role. The ones that cut tokens are context-mode and RTK, and they work at different layers.
rtk init -g printed a success message, but the PreToolUse hook was never registered. The cause was one leftover comma in settings.json.
Running several pod replicas led two pods to finalize the same job at once. How a single conditional UPDATE, the CAS pattern, stopped the race without a distributed lock.
Notes from Thariq Shihipar's Field Guide to Fable talk. With Fable, what decides the result is less the model's intelligence and more how much of what I don't know I surface before starting.