Learning Rust Did Not Replace Go

My retirement plans outgrew my spreadsheets. Go helped. Rust made it better. I still like Go better.

I had tracked expenses for years: first in a physical notepad, then Excel, an iPhone app, and eventually Google Sheets. Ready-made templates never quite fit. When I started planning for retirement, neither did the spreadsheets. I wanted to explore scenarios they couldn’t comfortably express, and the dedicated software felt too complex.

Turns out I’m a software engineer! Long ago, I built a Go CLI: a TOML file describing my plan went in, an HTML report came out. Simple, useful, limited. It helped organize my thoughts, but there were still things I couldn’t model.

With coding agents, I took another run at it. This time, as an excuse to learn Rust. I told the agent in AGENTS.md that learning was part of the goal, and quickly had something running while getting my head around ownership, borrowing, and lifetimes.

Oh, boy, that was fun. Rust is a delightful language.

Then I kept adding things. Changes took more effort than I expected, and the engineer in me kept asking whether this application needed Rust.

Here’s my hot take: for most application software, I think Go gives you 90% of Rust’s practical value with half the friction. There. I feel lighter.

I appreciate Rust’s control over memory, performance, and compile-time guarantees. But the complexity beyond the basics has a price. For this tool, I kept feeling it when I wanted to make changes. Go feels easier to understand and iterate on, with fewer ways to do the same thing.

AI didn’t make that tradeoff disappear. I was using top-tier models and reviewing every piece of code. They still made bad architectural decisions in a small app. A language’s guarantees don’t cover those.

I solved a problem and added Rust to my toolbelt. I just didn’t leave wanting Rust everywhere.

I still own the decision of which tool fits the job.