Atharva Pandey Gopherine

Goroutine leaks are the memory leaks of concurrent Go. They’re slow, invisible, and tend to surface only under load — or worse, only after days of continuous running when the service has accumulated tens of thousands of stuck goroutines. I’ve debugged two production incidents that traced back to leaks in code that had been in production for months, completely unnoticed during normal load.

The root cause is almost always the same: someone started a goroutine and didn’t give it a way to exit. Not a way to exit eventually — a way to exit in every possible code path.

The first time I demoed an LLM-powered feature to stakeholders, I made the rookie mistake of using non-streaming responses. The CEO asked a question, hit enter, and stared at a blank screen for eight seconds. “Is it broken?” No — it was thinking. But by the time the response appeared, she’d already mentally moved on to the next agenda item.

Streaming changes everything. Users see tokens appearing in real-time, which feels responsive even when the total generation time is identical. But implementing streaming in Rust? It’s one of those things that’s surprisingly nuanced once you get past the happy path.

Our Rust project started as a single crate. Then we split the API handlers from the domain logic. Then we extracted shared types. Then someone added a CLI tool. Then a worker service. Before we knew it, we had nine crates and cargo build was doing weird things because three of them depended on different versions of serde. That’s when we sat down and properly set up a workspace.

I’ve now managed Rust workspaces ranging from 5 crates to over 40. The patterns I’m going to share come from real mistakes — dependency hell, circular imports, CI builds that took 45 minutes, the works.

Last month I watched a coworker’s Python script silently swallow a malformed response from the OpenAI API. The choices field came back empty, the code plowed ahead with choices[0], and the whole pipeline crashed at 2 AM. Nobody got paged because the error handler was also broken. Classic.

That’s the moment I decided to rebuild our LLM integration layer in Rust. Not because I’m some Rust evangelist who thinks Python is evil — I use Python daily. But when you’re making API calls that cost real money and feed into production systems, maybe you want a type system that actually catches things before runtime.

“Goroutines are cheap” is something you read in every Go introduction. It’s true. A goroutine starts with a 2KB stack and the runtime handles scheduling. Spinning up a thousand of them is trivial. The part the introductions leave out is that “cheap” is not “free,” and goroutines that you start and never stop are a leak — one that doesn’t crash your program, just slowly eats your memory and degrades your scheduler until something gives.

I once inherited a codebase where someone had written a Python script that generated 4,000 lines of Rust from a YAML spec. The script ran outside of Cargo, the generated file was checked into git, and nobody remembered to re-run it when the spec changed. By the time I found it, the generated code and the spec had diverged in twelve places. That experience shaped how I think about code generation in Rust — it needs to be integrated into the build, not bolted on the side.

String DP has its own flavor that’s distinct from the two-string comparison problems of the last lesson. Here, the state is typically a single string, but the subproblem is about a range within that string: “what’s the answer for the substring s[i..j]?” That’s interval DP applied to strings, and palindromes are its most natural setting.

The tricky part with palindrome problems is that you can approach them from the outside in (is s[i..j] a palindrome?) or the inside out (expand from a center). DP works from the outside in: small intervals first, then build up to larger ones. The expansion approach is often faster in practice but DP is more general and extends to partition problems naturally.

I’ve been building systems software professionally for a while now, and here’s what I’ve noticed: the skills we’ve covered in this course — no_std programming, memory-mapped I/O, custom allocators, interrupt handlers, network protocols — they all converge when you build production systems software. A database engine is just a file system on top of a storage engine with a query processor. A network proxy is packet parsing plus connection management. A language runtime is memory management plus a scheduler.

Here’s a scenario that played out for me once: service is running fine for weeks, then we double traffic, and suddenly requests start timing out. Not all of them — maybe 10%. The logs show pq: sorry, too many clients already. Postgres is refusing connections. But we have a connection pool — that’s the whole point, right? Why is Postgres seeing more connections than it can handle?

Because database/sql’s default pool settings are almost certainly wrong for production, and most people never change them.

We had this rule on my old team: never use .unwrap() on database query results. We wrote it in our contributing guide. We mentioned it in code reviews. We added it to the onboarding doc. And yet, every single sprint, someone would push an .unwrap() on a sqlx::Result that would blow up in production at 2 AM. That’s when I decided to make the compiler enforce our rules instead of relying on humans to remember them.