Atharva Pandey Gopherine

I’ve written APIs in a dozen languages, and Rust is the only one where the community has near-universal agreement on how APIs should look. There’s an unofficial (but incredibly thorough) Rust API Guidelines document, and most popular crates follow it closely. When you learn these conventions, every new crate feels familiar.

Here’s what I’ve distilled from reading hundreds of crate APIs and writing a few of my own.

Naming Conventions

Rust has strong naming conventions, and deviating from them makes your crate feel alien.

Early in my career I deployed a Go service and checked top. The VIRT column showed 1.2 GB. I nearly had a heart attack — our server had 4 GB of RAM and I thought the service was consuming nearly a third of it. A senior engineer laughed and told me to look at RES instead: 52 MB. I had no idea what the difference was. Understanding virtual memory is fundamental to reading memory metrics correctly, debugging out-of-memory kills, and understanding how processes interact with the kernel.

You made it. Twenty-five lessons ago you didn’t know what package main meant. Now you understand variables, types, functions, error handling, interfaces, goroutines, testing, JSON, file I/O, the type system, and the entire toolchain. That is not beginner knowledge anymore.

But there’s a gap between knowing the language and writing Go the way experienced Go developers write it. This lesson is about that gap — what it is, how to close it, and what to build while you do.

When I first saw PhantomData in a codebase, I thought it was some kind of hack. A zero-sized field that exists only to satisfy the compiler? It felt like a workaround for a language limitation. But the more I used it, the more I realized it’s actually a precision tool — it lets you encode information in the type system without any runtime cost.

We already used it in the typestate lesson. Now let’s understand it properly.

I used to dread behavioral interviews. I was confident in system design rounds, reasonably calm under algorithm pressure, but the moment someone said “tell me about a time you disagreed with a technical decision,” I felt my brain empty out completely. I would ramble for two minutes, lose the thread halfway through, and trail off into something like “…so yeah, it worked out eventually.” Not exactly compelling.

The STAR method fixed that — not because it’s magic, but because it gives a structure that stops you from wandering. Situation, Task, Action, Result. Four buckets. Every behavioral answer you’ll ever give fits into them.

Binary search has a reputation as the thing you learned in your first CS course and never thought about deeply again. Then you encounter a rotated array or a capacity-minimization problem in an interview, and suddenly it is not obvious at all. I’ve seen engineers who could recite the textbook implementation fail completely on problems that are, at their core, binary search — because the search space isn’t an array of values, it’s something more abstract.

In Go, you write defer f.Close() and hope you didn’t forget one. In Python, you use with blocks and hope the context manager is implemented correctly. In Java, you use try-with-resources and hope AutoCloseable.close() doesn’t throw. In C, you write free() and pray.

In Rust, cleanup happens automatically when a value goes out of scope. Always. No exceptions. No forgetting. That’s RAII — Resource Acquisition Is Initialization — and the Drop trait is how Rust implements it.

I once joined a team that had a users table with 8 million rows. The GET /users/{email} endpoint was consistently timing out under load. When I ran EXPLAIN ANALYZE on the query, I saw it: Seq Scan on users (cost=0.00..180000.00 rows=1 width=120) (actual rows=1 loops=1). It was reading every single row — all 8 million of them — to find one user by email. Adding a single index fixed it in under five minutes. That experience made me want to actually understand what an index is, not just that it makes things faster.

Most engineers use maybe 15% of Git. add, commit, push, pull, branch, merge, and status covers daily work. That’s fine until you need to find which commit introduced a regression across 300 commits, or you need to untangle a messy history before merging, or you want to work on three features simultaneously without context-switching overhead. The commands I’m covering here don’t come up every day. When they do, they save hours.

One of the things that drew me to Go was that the toolchain ships with the language. You don’t need to choose a build tool, a formatter, or a test framework — they’re all there from day one, and they’re all invoked the same way: go <command>. This lesson is a tour of the tools you’ll use every single day.

The Basics

go run and go build

You’ve used go run throughout this course. It compiles your code and immediately executes it — perfect for development. Under the hood it creates a temporary binary and runs it, then throws the binary away.