A preface,
by way of confession

My name is James Ainslie, and I have been doing this for about thirty years. I will spare you the full chronology; the shape of it is that I started in computer engineering, spent a long stretch building and running companies, and never managed to stop writing code while doing it. In South Africa I founded Cloudseed and scaled a managed services platform to two million users across twenty-five hundred locations, which is where I learned the lesson that has organized everything since: systems fail at the seams, and the seams are where the interesting work is.

Today I am a Distinguished Engineer at GEICO, where I serve as lead architect for observability, rebuilding the company's telemetry platform from the ground up on open standards. That platform is Titan, which I built and engineered on the Grafana open source MELT stack, and it watches 1.5 billion active time series and petabytes of log telemetry arriving at many millions of events a second, across AWS, Azure, and private cloud, which is a polite way of saying that when it pages, it matters. Its successor, Titan v2, is being engineered for the next order of magnitude: hundreds of millions of events a second across metrics, traces, and logs, with a p99 query latency under one second for any query you can pose it. The name is a debt acknowledged: the industry's standard-bearer for metrics is Prometheus, and Prometheus was, of course, a Titan. I confess, humbly, to an obsession with the classics that the reader will catch recurring throughout this preface, and I decline to apologize for it; the Greeks named every force that shapes a system several millennia before we had systems. On the side of all that I co-founded yaklab, a small software cooperative devoted to beautiful software and open source tooling, on the theory that the word “beautiful” belongs in engineering and we intend to keep putting it there.

Three decades in, the honest summary is that I still care most about the craft. Everything else in this preface is detail.

You can judge an engineer by what is on the bench, so here is mine. At GEICO, the observability rebuild has taken the form of a small fleet of systems, named, as these things should be, from the Greek:

Outside of work the corpus lives on GitHub under jamesainslie: dozens of tools in Go and TypeScript, from CLI scaffolding and Kubernetes dashboards to Mermaid renderers and MCP servers, the steady sediment of a person who automates whatever annoys him twice. And under yaklabcosits the cooperative's tooling, of which I will single out stave, our Go build system, whose repository description says most of what you need to know about the organization's temperament: because any good wizard has a stave.

I am, humbly, a polyglot, which is a grand word for someone who has been let down in several languages. But the first love was not a language at all; it was an operating system. I found FreeBSD early, and FreeBSD, improbably, found me back: a handful of its core committers took a young engineer seriously enough to mentor him, and it was through their patience that I fell in love with software engineering itself. With the project came C, the language the system is made of, where you know what every byte costs because you are personally acquainted with all of them. And with the code came the community's principles, which marked me at least as deeply: correctness over cleverness, documentation as a first-class duty, review as a form of respect, and the principle of least astonishment held very nearly as law. Everything I have admired in an engineering culture since has been an echo of that one.

Then, like much of my generation, I got lost for years in Ruby and Python. Lost is the right word. Both languages are seductive in the small and treacherous in the large, and I came, honestly, to hate them both: Ruby for the way its elegance dissolves into runtime surprise, metaprogramming magic, and performance apologetics; Python for the way it lets a system grow to a hundred thousand lines before mentioning that types were optional, packaging was folklore, and the speed you needed was in some other language wearing a C extension. They are fine tools for what they are. What they are not is honest about scale, and I was building at scale.

Then I found Go, and it was, without embarrassment, love. A small language with a fast compiler and one binary at the end; concurrency you could reason about; a community that treated boredom as a virtue. Go restored my belief that a language could respect both the machine and my time, and the tens of thousands of Go files in my repositories are the receipts of a long and happy marriage that continues to this day.

But all through those years, Rust sat on the horizon. I eyed it the way you eye a mountain from a comfortable valley: with admiration, with the suspicion that the view from up there justified the climb, and with a dozen excellent reasons to stay where the weather was kind. The borrow checker's reputation preceded it. The systems I was building kept almost needing it. I kept almost starting.

This corpus is what “almost starting” finally became. I wanted to learn Rust, properly, and I know only one method that has ever worked on me: to explain a thing until I cannot hide from the parts I do not understand. So I wrote the book I needed, chapter by chapter, in the order the language actually demands, and held myself to the standard each chapter sets for its reader. Writing it was the apprenticeship. The chapters on ownership were written by someone arguing with the borrow checker that same week; their patience with you is the patience I needed and went looking for.

And the conclusion can now be stated plainly, because the book is complete: the fluency took. Toil, the Rust hull in the fleet above, exists because somewhere past the middle chapters the language stopped being a mountain and became a tool, and the climb turned out to be the interesting part. The compiler did become the tutor. The wall did move from 3 a.m. to 3 p.m. Everything chapter 1 promises was promised first to me, and kept.

A last word, about the word book. This one will never sit on a shelf. It is published on the internet, a handful of pages conjured by a browser, and every contemporary taxonomy has a name ready for such a thing: a site, a series, docs, content. I cannot bring myself to use any of them. My career may have begun in computer engineering, but my education was in the arts, not the sciences, and the arts leave you with convictions that outlast every technology you later acquire. Chief among mine is this: a sustained thesis, one with a beginning that makes promises, a middle that keeps them, and an ending that knows itself to be an ending, is a book, whatever it happens to be printed on.

The substrate has never been the point. The form has survived clay, papyrus, vellum, paper, and now phosphor, and it survived each migration because the form was never about the material; it was about the contract. “Content” is what fills a container, measured by volume and abandoned without guilt. A book is the opposite of a container: it is a commitment, an argument that agrees in advance to be accountable to its own first chapter. Call a thing content and you license yourself to wander off mid-paragraph; call it a book and you owe the reader an arc, and the reader owes you their attention in order, and both debts are the honorable kind. The sciences gave me the means to write this one. The arts gave me the refusal to call it anything less than what it is. So: a book. Read it the way books ask to be read, beginning to end, at length, with a pencil's attitude even where there is no pencil.

James Ainslie
somewhere between a Go binary and a borrow checker, 2026