Atharva Pandey Gopherine

A few months ago, someone filed a soundness bug against a crate I maintained. The report was elegant — three lines of safe code that triggered a use-after-free through my API. No unsafe in the caller’s code. The bug was in my unsafe implementation. I fixed it within the hour, cut a patch release, and filed a CVE advisory. That’s the social contract of soundness in Rust: if safe code can cause undefined behavior, the bug is always in the library.

The first time I looked at what #[wasm_bindgen] actually generates, I was equal parts impressed and horrified. Impressed because it seamlessly bridges two fundamentally different type systems. Horrified because the generated code is a labyrinth of pointer arithmetic, descriptor tables, and heap management. But here’s the thing — you don’t need to understand every line of generated code. You do need to understand the model, because when things go wrong (and they will), the model is what helps you debug.

There is a category of service that I have built many times and will build many more times: an API that creates, reads, updates, and deletes records in a relational database, with some validation and authentication. There is nothing glamorous about it, and there is nothing architecturally complex about it either. The correct implementation is straightforward, fast to build, easy to test, and easy to read. The over-engineered implementation has event sourcing, CQRS, a message bus, six layers of abstraction, and takes three months to build something that the straightforward implementation would have shipped in two weeks.

We had a Node.js microservice that validated JWTs. Under load, the jsonwebtoken npm package was burning 40% of CPU on RSA signature verification. I wrote the verification in Rust with napi-rs, dropped it in as a replacement, and CPU usage fell to 8%. The JavaScript API didn’t change at all — same function name, same arguments, same return type. Just 5x faster.

napi-rs is to Node.js what PyO3 is to Python. You write Rust, export it as a native Node addon, and call it from JavaScript like any other module. The framework handles all the N-API complexity, type marshaling, and async integration.

I was optimizing a client-side image processing pipeline last year — think heavy convolutions, histogram equalization, color space conversions. The JavaScript implementation was doing about 12 frames per second. I rewrote the core loops in Rust, compiled to WebAssembly, and hit 55 fps. Same browser. Same machine. That’s the moment WebAssembly stopped being a curiosity and became a tool I actually reach for.

But let me be real: getting there wasn’t a straight line. The tooling has rough edges, the mental model is different from writing server-side Rust, and half the blog posts out there show you how to add two numbers in WASM and call it a tutorial. That’s not what we’re doing here.

Every time you open a file, acquire a lock, or start a database transaction, you’ve created a resource that needs to be released when you’re done with it. In most languages you manage this with finally blocks or RAII patterns. Miss one cleanup and you’ve got a leak. Go has defer, and once it clicks, you’ll wonder how you ever coded without it.

The Problem

Here’s what resource cleanup looks like without defer. Real code, the kind that ships:

I had a Python service that processed 2 million JSON records daily. Profiling showed 80% of the time was spent in one function — a custom similarity scoring algorithm. I rewrote that single function in Rust with PyO3. Same API, same tests, same deployment. Processing time dropped from 47 minutes to 90 seconds. The Python team didn’t have to learn Rust, didn’t have to change their imports, didn’t even notice — they just saw their pipeline get 30x faster.

Climbing Stairs and House Robber have a comfortable property: dp[i] depends on just the previous one or two positions. Each step you take looks back a fixed distance. These are the training wheels problems.

Advanced 1D DP breaks that comfort. Word Break needs to look back up to the entire string. LIS needs to look back at every prior element. Coin Change loops over all denominations at every position. The look-back window is variable, sometimes unbounded. The dp array is still 1D — but you need a loop inside a loop.

A team I was advising had a massive C codebase — about 400,000 lines of networking code. They wanted to rewrite their TLS handling in Rust but couldn’t justify a full rewrite. The solution: build Rust as a shared library, expose a C-compatible API, and link it into the existing build. Took a week to get the first version working. The memory safety bugs in that module dropped to zero.

There’s a moment in every Go developer’s journey where the serial loop stops being acceptable. You’ve got 200 URLs to fetch, 500 records to transform, 50 API calls to make — and you’re doing them one at a time. The fix feels obvious: spin up goroutines. But spin them up without a plan and you’ve traded one problem for three.

Fan-out / fan-in is the pattern that makes parallel work manageable. Fan-out means distributing a stream of work across multiple goroutines. Fan-in means collecting their results into a single channel. Simple in concept, surprisingly easy to get wrong in practice.