Atharva Pandey Gopherine

True story: a Mars orbiter was lost because one team used pounds and another used newtons. Same numeric type, different semantic meanings. $327 million, gone.

You’d think we’d have learned. But I still see codebases where user IDs, product IDs, and order IDs are all i64. Where distances are f64 whether they’re meters or feet. Where an email address is just a String that you hope someone validated.

The newtype pattern fixes this. It gives you type safety with zero runtime cost.

Almost every program I write these days talks to something over HTTP — a third-party API, a database service, a webhook. And almost everything speaks JSON. So learning how Go handles JSON and HTTP isn’t an advanced topic; it’s one of the most practical skills you can pick up early.

In this lesson I’ll walk you through converting Go structs to JSON and back, decoding JSON from an API response, and making real HTTP requests — all using only Go’s standard library. No third-party packages needed.

Every system design interview starts with the same silent assumption: you already know how the internet works. Interviewers won’t ask you to explain DNS. But when you confidently say “the client calls the API” without being able to say what actually happens between those words, the cracks show up in your design. Understanding the layers — DNS, TCP, HTTP, TLS — isn’t trivia. It’s the mental model that tells you where latency hides, why connections are expensive, and what breaks under load.

I once spent two days debugging a production issue where someone called .send() on an HTTP request builder before setting the URL. The code compiled fine — it was a runtime error that only surfaced under specific conditions. In Python. In Java. In Go. This kind of bug is everywhere.

In Rust, you can make it literally impossible to compile. The typestate pattern encodes state transitions into the type system. If the state machine says you can’t send before setting a URL, the compiler enforces it. Not with runtime checks. Not with assertions. With types.

You’ve made it through 24 lessons. You understand ownership, borrowing, structs, enums, traits, generics, error handling, closures, iterators, and file I/O. That’s not nothing — that’s the foundation of every Rust program ever written. But foundations are for building on. Here’s where to go from here.

What You Know Now

Take a second to appreciate what you’ve learned. You can:

• Set up a Rust project with Cargo
• Write functions with proper ownership and borrowing
• Model data with structs and enums
• Handle errors with Result and the ? operator
• Use collections: Vec, HashMap, HashSet
• Write generic code with trait bounds
• Process data with iterators and closures
• Test your code with #[test]
• Read and write files

That’s a real skill set. You can build useful things right now. Before diving into advanced topics, I strongly recommend you build something. Nothing fancy — a command-line tool, a file processor, a simple data structure. The gap between “I understand the concepts” and “I can write a program” is only bridged by practice.

I used to write Rust like I was still writing C — for loops everywhere, mutable accumulators, index variables. The code worked, but it was loud. Five lines to express what should be one. Then I started using iterator chains, and honestly? I’m never going back.

Iterator chains aren’t just syntactic sugar. They’re often faster than hand-written loops because the compiler can optimize them better. Zero-cost abstractions in action.

The Imperative Way vs The Idiomatic Way

Here’s a task: given a list of strings, find all that start with “error:”, strip the prefix, trim whitespace, and collect the results.

I spent two years writing Go services before I really internalized Big-O. Not because I didn’t know the notation — every CS course teaches you to recite O(n log n) — but because I never tied it to a real decision I had to make in production. It clicked for me the day a coworker asked, “will this work when we have a million users?” and I had no honest answer.

I used to think testing was something you did after you finished writing code — a checkbox you ticked before committing. Go changed that attitude for me, not by lecturing me about best practices, but by making testing so straightforward that there was no excuse not to do it. The tooling is built in, the conventions are clear, and writing a test in Go takes about as long as writing the function itself. After a few weeks with Go, I started writing tests alongside my code, then slightly before it. The feedback loop became addictive.

Every tutorial teaches you to manipulate data in memory, but real programs read from files and write to files. Rust’s file I/O is built on the same ownership and error handling principles you’ve been learning — and once you see how Result, iterators, and traits come together, the entire language design starts to feel cohesive.

Reading a File — The Quick Way

use std::fs;

fn main() {
    match fs::read_to_string("hello.txt") {
        Ok(content) => println!("File contents:\n{content}"),
        Err(e) => eprintln!("Error reading file: {e}"),
    }
}

fs::read_to_string reads the entire file into a String. It returns Result<String, io::Error> — because file operations can fail (file doesn’t exist, permission denied, disk error, etc.).

There’s a special kind of code smell that I call “match bloat” — when you write a six-line match statement to handle a single variant and throw an underscore wildcard on everything else. I wrote hundreds of these before discovering that Rust has a better way.

If you’re writing match just to handle one case, you’re doing too much work.

The Problem: Match Bloat

Here’s code I see all the time, especially from developers coming from the previous lesson on Option and Result: