Atharva Pandey Gopherine

1D DP was a single row — you filled it left to right and you were done. 2D DP extends that to a full table. You fill it row by row, and each cell depends on cells above it, to its left, or diagonally above-left. The shape of that dependency is the shape of the problem.

I find 2D DP more intuitive than 1D once I got comfortable with the table visualization. Unique Paths is a perfect first problem because you can literally draw the grid and fill it in by hand in 30 seconds. Edit Distance is the crown jewel — once you understand why the three transitions correspond to the three edit operations, you’ll never forget the recurrence.

I bricked my first development board within forty-five minutes of getting it out of the box. Wrote some C code, forgot to configure the clock properly, flashed it, and the thing just… stopped responding. No debugger connection. No serial output. A $15 paperweight.

That experience — the raw, unforgiving nature of hardware programming — is exactly why Rust matters in embedded. Not because it prevents you from writing to the wrong register (it can’t, really), but because it gives you tools to structure hardware access so mistakes become harder to make.

“WASM is faster than JavaScript.” I’ve heard this so many times, and it drives me nuts — not because it’s wrong, but because it’s incomplete. WASM can be faster than JavaScript. It can also be slower. The difference depends on what you’re doing, how you’re crossing the JS↔WASM boundary, and whether you’ve hit the specific scenarios where WASM’s architecture actually gives you an advantage.

I ran benchmarks for months to figure out where the real boundaries are. Let me show you the data.

The first time I tried to compile a Rust program with #![no_std], I felt like someone had pulled the floor out from under me. No println!. No String. No Vec. No HashMap. Half the stuff I relied on daily — just gone.

And that’s exactly the point.

Why Would Anyone Do This?

Here’s the thing most Rust tutorials won’t tell you up front: the standard library is enormous. It pulls in heap allocation, threading, file I/O, networking, and a whole OS-level runtime. That’s great for application development. It’s a non-starter for:

An agent is a loop: observe, think, act, repeat. The LLM is the “think” step — it decides what to do next given the current state. Your Go code handles “observe” (gathering context), “act” (executing tool calls), and the loop control that keeps everything running. I’ve built agents that write and execute code, agents that browse the web, and agents that orchestrate multi-step data pipelines. The underlying architecture is always the same few patterns, and Go’s concurrency makes the execution layer clean and fast.

Production Go codebases that run fine in staging will sometimes crater under real traffic. More often than not, the cause is unbounded goroutine creation. Some background job processor spins up a goroutine per message. The queue backs up. Suddenly there are 50,000 goroutines fighting for CPU, exhausting file descriptors, allocating gigabytes of stack space. The service falls over. The incident post-mortem says “we didn’t expect this load.” The real cause: no worker pool.

I spent a long time reaching for third-party database libraries in Go before I actually read the database/sql docs. When I finally did, I was embarrassed — the stdlib had everything I needed and I’d been adding dependencies for no reason. The problem isn’t that database/sql is limited. The problem is that it has a handful of non-obvious behaviors that, if you don’t know about them, will burn you in production. Once you internalize those, you’ll write better database code than most people using ORMs.

After building that todo list with raw web-sys in Lesson 3, I think we can all agree: manually managing DOM nodes, closures wrapped in Rc<RefCell<Option<Closure<dyn FnMut()>>>>, and string-based style attributes isn’t how anyone wants to build a real application. That’s where Rust frontend frameworks come in. And we’ve got three serious contenders — each with a different philosophy about how to build web UIs.

I’ve built side projects with all three. Let me tell you what actually matters when choosing between them.

There’s something deeply satisfying about writing document.create_element("div") in Rust and watching it actually work in a browser. It’s also, if I’m being honest, kind of painful — because web-sys wraps every single Web API call in Result types, and you end up with .unwrap() chains that would make any Rustacean cringe. But once you build the right abstractions on top, it becomes surprisingly pleasant. Let me show you how I got there.

String concatenation with + is one of the most common performance bugs I see in Go code reviews. Not because developers are careless, but because the bug is invisible — the code looks clean and correct. result += piece is obvious. The quadratic memory behavior that follows is not.

The strings and bytes packages are where Go provides the right tools for this job. strings.Builder and bytes.Buffer are both efficient for incremental string construction, but they’re not the same type and the choice between them matters in specific cases. Beyond building strings, these packages contain functions that have non-obvious but significant performance implications: strings.Contains vs strings.Index, strings.Split vs strings.SplitN, and the ones people reach for that they shouldn’t.