Atharva Pandey Gopherine

I’ve reviewed auth implementations at four different companies. Three of them stored passwords in SHA-256 without salting. One stored them in plain text in a column called password_encrypted — because naming it “encrypted” apparently counted as security. Auth is the part of your application that bad actors actively try to break. Getting it wrong isn’t a bug, it’s a liability.

Password Hashing: Do This Right or Don’t Do It At All

Before we talk about tokens or sessions, let’s nail password storage. The rules are simple and non-negotiable:

Most candidates treat sorting as a black box — call sort.Ints and move on. That works until an interviewer says “can you do this without sorting?” or “implement this yourself” or “what’s the worst-case time?” At that point, not understanding sorting costs you the offer.

I don’t mean you need to memorize every sorting algorithm. You need three things: understand merge sort well enough to implement it (divide-and-conquer is a pattern you’ll use in other contexts); know QuickSelect for kth-element problems (it’s O(n) average and comes up constantly); and know when sorting is all you need and when the comparison lower bound of O(n log n) is a limit you can break. This lesson teaches all three.

I used to litter my Rust code with .to_string(), as, and manual conversion functions everywhere. Then I learned the conversion traits properly and my APIs went from clunky to clean. These traits are the glue that makes Rust code feel ergonomic — and understanding when to implement each one is the difference between a library that’s pleasant to use and one that makes people curse your name.

From and Into — Infallible Conversion

From<T> defines how to create a type from another type. It can’t fail. If there’s any possibility of failure, you want TryFrom instead.

Struct tags are one of Go’s most practically useful metaprogramming tools and one of its least formally documented features. The syntax is simple — a raw string literal after the field type in a struct — but the convention built on top of it powers nearly every serialization library, ORM, validator, and configuration loader in the ecosystem. Understanding how tags work at the reflection level demystifies why encoding/json knows to use omitempty, why database/sql scanners can map column names to struct fields, and how you can build your own tag-driven behavior.

A junior engineer on my team once deployed an endpoint that accepted any string as an email address. Someone submitted “lol” as their email, the downstream email service threw a cryptic error, and our error tracking lit up with 500s for an hour. Input validation isn’t glamorous, but skipping it is how you get paged at dinner.

The Problem with Default Error Responses

Out of the box, Axum’s error responses are… not great. Send malformed JSON to a Json<T> handler and you get back:

Search is the feature that separates usable products from unusable ones at scale. When your application has thousands of documents, a sequential scan works. At millions, it doesn’t. The difference between a search box that works and one that times out is a data structure invented in the 1960s that every modern search engine still fundamentally relies on: the inverted index. Understanding how it works — and how to build a system around it — is what this lesson is about.

Most Go developers approach LLM APIs the same way they approach any REST API — write an HTTP client, handle errors, parse JSON. That instinct is correct, but LLM APIs have a few characteristics that require specific handling: they’re slow (seconds, not milliseconds), they have complex nested response structures, they support streaming, and the model selection and token management have real cost implications. This lesson is about building Go clients that handle all of this properly.

I once inherited a Node.js codebase with 23 Express middleware functions chained together. Half of them silently swallowed errors, three of them conflicted with each other, and nobody knew what order they ran in. When I started building services in Axum, the Tower middleware model felt like a revelation — not because it’s easier (it’s actually harder at first), but because it makes middleware composable and type-checked. You can’t silently swallow errors when the type system forces you to handle them.

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.

I shipped a data race to production exactly once. Go program, shared map, no lock. Took three weeks to reproduce — only happened under heavy load when two goroutines hit the same key simultaneously. The crash dump was useless. In Rust, that code wouldn’t have compiled. That’s not marketing — it’s literally how the type system works.

Arc — Shared Ownership Across Threads

Before we talk about locks, we need Arc. You can’t share data between threads with just Rc — it’s not thread-safe. Arc (Atomic Reference Counted) is the thread-safe version.