About — Gopheria

Why this site exists

Gopheria publishes long-form writing about Go: the language, its runtime, its frameworks, and the ecosystem that has grown around them. The tagline is the editorial policy — Go, beneath the surface. Most of what is written about Go on the open web either restates the documentation or hands out a rule of thumb with nothing behind it. Both are cheap to produce, which is why there is so much of both. This site is interested in the layer underneath: why the scheduler made that choice, what a benchmark is actually measuring, where an abstraction leaks once it is under load.

The goal is narrower than “explaining Go”. It is to publish claims a reader can check without trusting the writer. Every statement here about how something behaves or how fast it runs arrives with the Go version it was observed on, the machine it ran on, a command, and the output — and the harness that produced that output is kept runnable in a public experiments repository, because a published number whose code has been thrown away is an assertion again. What should accumulate over the years is a corpus that stays useful because each piece of it is dated, versioned, and repeatable, not because it was right in general.

The reader is asked for nothing in return. No advertising, no sponsored placements, no newsletter gate, no comment system, and no cookies — analytics, where present, are cookieless and aggregate. Reading is the whole transaction. The corpus is also served in a form machines can quote: every post exists as plain Markdown at its URL plus .md, and the complete set lives at /llms-full.txt.

Who writes here

Nolan Keir writes about Go, backend engineering, and the systems behind production software. His work focuses on concurrency, runtime behavior, performance, tooling, and the trade-offs hidden behind clean abstractions. He prefers reproducible experiments and measurable behavior over rules of thumb. He writes at Gopheria. In practice that means goroutine scheduling when a syscall blocks a P, escape analysis read against -gcflags=-m rather than against intuition, what a GC cycle costs a sync.Pool, allocation profiles that disagree with the CPU profile, contention curves where atomics stop beating a mutex — and the toolchain that makes any of it visible.

The stance comes out of running these systems, not out of reading about them. He has been burned by cargo-culted advice and it shows: he distrusts round numbers, unsourced claims, and any sentence containing “always” or “never” about performance. Articles here tend to start from something that went wrong in production rather than from a topic worth covering, which is why they usually open with the answer most people hold and then show where it stops being true. When a profile does not explain a number, the article says “I don’t know why” and leaves the question open. He is not the smartest person in the room and does not perform being one; he is the one who ran the experiment.

What gets written, and what does not

Coverage sits on four pillars, and every post belongs to exactly one: runtime internals (the scheduler, the allocator, the GC, stacks, the netpoller), concurrency in practice (channels, sync, context, and which patterns survive production), performance and measurement (benchmarking method, profiling, escape analysis, compiler behaviour), and the ecosystem and its tooling, judged against the same standard as everything else. A subject earns a slot when it can be turned into a question with a measurable answer. If the experiment cannot be built, the piece is not written — and when a finished experiment contradicts the angle it was meant to support, the finding wins and the angle is rewritten.

Every claim about behaviour or speed ships with the means to check it:

the exact Go version, because runtime behaviour is not eternal;
the machine it was measured on;
a command you can run;
the actual output, pasted rather than summarised.

Benchmarks are run with -benchmem, at least ten times, and compared with benchstat. Differences are reported with their variance. When a result lands inside the noise, the article says so and keeps the section — a negative result is still a result, and it is the kind nobody else publishes. Where an experiment does not model something, the article states what it misses; one honest sentence about a limitation is worth more than a paragraph of hedging.

What is deliberately absent: syntax lessons, listicles, release notes rewritten as news, framework opinions with no numbers attached, and rules of thumb without the boundary at which they invert. The audience is working Go developers who already read Go fluently, so nothing here explains defer from scratch. If a claim was never measured, it is not made — the sentence says “I have not measured this” instead.

How an article gets made

One byline signs every article, and the process behind it is not a secret:

The author picks the subject and writes the draft. Nolan chooses what is worth measuring and writes the first version himself, from real production systems: what broke, what the profile said, what the fix actually cost. That draft carries what a first draft carries — service names and load figures belonging to systems that are not his to publish, and prose written at the speed of the thought behind it.
An AI pass anonymises it and cleans up the prose. The identifying details of the production system are stripped and replaced by a reproducible harness that reconstructs the same conditions on a named machine. Typos, broken sentences, and tangled expression are repaired, and the result is a publication-ready text. No claim and no number is introduced at this step that the author did not measure; the pass edits how the piece reads, never what it asserts.
The author reviews it before it publishes. Nolan reads the edited text line by line against the harness output, corrects anything the cleanup smoothed into something that is no longer true, and gives the piece its final shape. Nothing publishes that he has not signed off on.

This is written down because a reader is entitled to know how the text in front of them was produced. It is also the reason articles show a synthetic harness instead of the production system a story started in, and the reason the numbers are re-measured on a machine the article names rather than quoted from a dashboard nobody else can open. Responsibility for every published claim is the author’s, at every step.

Corrections are welcome and get published. If a benchmark here does not reproduce on your machine, that is worth an email — it usually means the article failed to state a condition it depended on.

[email protected]