Atharva Pandey Gopherine

I spent two years writing Go services before I genuinely understood why iterating over a two-dimensional slice in the wrong order could tank my throughput by 5x. It wasn’t a bug. It wasn’t a bad algorithm. It was cache lines.

Arrays are the first data structure everyone learns and the last one most engineers actually understand. This is my attempt to fix that — not with theory, but with the reasoning that makes you a better systems engineer.

I once inherited a C codebase where -1 meant “not found,” 0 meant “error,” and NULL meant… well, it depended on the function. Sometimes it meant “empty,” sometimes “uninitialized,” sometimes “we ran out of memory.” The codebase had roughly 40 unique sentinel values across different modules, and half the bugs were someone forgetting which magic number meant what.

Rust looked at that mess and said: “How about we just… don’t.”

I have a rule: I won’t merge code without tests. Not because I’m a purist — because I’ve been burned too many times. Rust makes testing so frictionless that there’s no excuse to skip it. Tests live in the same file as your code. They run with one command. The tooling just works.

Your First Test

fn add(a: i32, b: i32) -> i32 {
    a + b
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_add() {
        assert_eq!(add(2, 3), 5);
    }

    #[test]
    fn test_add_negative() {
        assert_eq!(add(-1, 1), 0);
    }

    #[test]
    fn test_add_zero() {
        assert_eq!(add(0, 0), 0);
    }
}

Run with cargo test:

The stack is one of those data structures that seems too simple to be interesting — push, pop, peek, done. Then you sit in an interview, stare at a problem about brackets or expression evaluation, and realize you’re reaching for exactly this tool. I’ve seen candidates overcomplicate parenthesis validation with counters and flags when a stack makes it four lines of logic. I’ve also seen the reverse: candidates who knew the stack solution for valid parentheses but couldn’t extend the thinking to a harder variant.

A colleague once showed me their Rust code where every function parameter was String — never &str, never &String. When I asked why, they said “the borrow checker kept yelling at me, so I just take ownership of everything.” Classic.

I get it. The borrow checker can feel like an overzealous hall monitor. But once you understand the borrowing rules — really understand them — you’ll realize it’s not restricting you. It’s showing you a better design.

I once profiled a Go service and found it was spending 40% of CPU time allocating intermediate slices in a data pipeline. Each transformation created a new slice, copied data, processed it, then created another. In Rust, iterator chains do the same transformation with zero intermediate allocations. The data flows through the pipeline element by element, transformed in place. That’s not just elegant — it’s measurably faster.

The Iterator Trait

At its core, an iterator is any type that implements the Iterator trait:

There’s a moment in every Go developer’s journey when they realize that starting an operation isn’t the hard part — stopping it cleanly is. What happens when a user cancels a request? What happens when a database query takes 30 seconds instead of 300 milliseconds? Without a way to communicate “stop what you’re doing,” those goroutines keep running, consuming resources for something that no longer matters.

That’s the problem context solves. It gives you a standard way to carry a cancellation signal, a deadline, and a small amount of request-scoped data through your entire call stack. Once you understand it, you’ll see why the Go standard library passes it as the first parameter to almost every function that does I/O.

Closures are where Rust stops feeling like a systems language and starts feeling like a functional one. You’ve already been using them — every time you passed |x| x * 2 to .map() or |a, b| a.cmp(b) to .sort_by(), that was a closure. Time to understand what’s actually happening under the hood.

What Is a Closure?

A closure is an anonymous function that can capture variables from its surrounding scope:

I spent three months fighting the borrow checker before I realized the problem wasn’t the borrow checker — it was me. I kept thinking in C++ pointers and Java references. Every String was just “data on the heap.” Every function call was “passing a reference.” And every compiler error felt like Rust was being unreasonable.

It wasn’t. I was just thinking about memory the wrong way.

The C++/Java Mental Model (And Why It Fails)

If you come from C++, your brain maps everything to raw pointers, smart pointers, or references. If you come from Java/Python/Go, everything is a reference behind the scenes — you never think about who owns what, because the GC handles it.

YouTube serves over 500 hours of video uploaded every minute and delivers billions of views per day. When I first studied this problem seriously, I made the mistake of treating it as a simple “upload file, store it, serve it” exercise. It isn’t. The interesting engineering is in what happens between the moment a creator hits upload and the moment a viewer’s video starts playing seamlessly on a 3G connection in rural India. That gap is where the system design lives.