I write Go. Basically all day. Our backend services at the fintech startup are Go, and I genuinely like the language. Simple, fast to compile, easy to deploy, boring in the best way.
So why am I spending evenings reading the Rust book?
It started with a parsing service. We ingest a lot of financial data – news feeds, filings, scraped content – and one of our pipeline stages was chewing through memory in ways that made me nervous. Go’s garbage collector is good, but “good” still means occasional latency spikes when you’re allocating like crazy. I started wondering: what if we didn’t have a garbage collector at all?
That’s the pitch with Rust, basically. Memory safety without the GC. You get compile-time guarantees that you won’t hit null dereferences, use-after-free, or data races. The compiler yells at you instead of production.
What actually impressed me
The ownership model is the thing everyone talks about, and honestly, it deserves the hype. In Go, I’m used to reasoning about who’s holding a reference to what, but it’s all in my head. Rust puts it in the type system. The compiler enforces it. You literally can’t compile code that has a data race.
That’s wild to me.
Error handling is another win. Go’s if err != nil pattern is fine, I’ve defended it plenty of times. But Rust’s Result type with the ? operator is genuinely more ergonomic:
fn read_user(id: UserId, db: &Db) -> Result<User, DbError> {
let row = db.get(id)?;
Ok(User::from_row(row)?)
}
Compact. Every failure path is explicit and visible. No hidden exceptions, no panics you didn’t expect. I appreciate that.
And the performance characteristics are real. No GC pauses means your tail latency stays flat. For a service that needs to respond in single-digit milliseconds under load, that matters. I’ve been benchmarking a small parser in Rust vs our Go equivalent, and the Rust version uses about a third of the memory with more predictable response times.
Where it hurts
I’m not going to pretend this has been smooth.
The learning curve is steep. Ownership and borrowing make sense conceptually, but fighting the borrow checker for the first couple weeks is genuinely frustrating. There were moments where I knew the code was correct but couldn’t convince the compiler. That’s a different kind of pain than Go, where the language mostly gets out of your way.
Compile times. Oh, the compile times. Coming from Go, where a full rebuild takes seconds, waiting for Rust to chew through dependencies feels like going back in time. Incremental builds help, but the first build of a project with a handful of crates? Go make coffee.
The ecosystem in early 2018 is… young. serde is great, hyper is solid, tokio works. But the moment you need something less common – a specific database driver, an integration with a particular message queue – you might be writing it yourself or depending on a crate with 12 stars and one contributor. In Go, I take the standard library and rich ecosystem for granted.
And async is still rough. Futures exist, but ergonomic async/await syntax isn’t stable yet. Writing async Rust today involves a lot of ceremony that Go handles with goroutines and channels almost effortlessly.
Would I use it at the fintech startup?
I’ve been thinking about this specifically. Not “is Rust good” – it clearly is – but “should we adopt it here, now, for our stuff.”
The honest answer: selectively, maybe.
Our data ingestion pipeline is the obvious candidate. It’s CPU-bound, memory-intensive, processes untrusted input, and needs predictable latency. Rust fits that profile perfectly. I could see rewriting the parsing stage as a standalone Rust service behind a clear API boundary. Keep everything else in Go. No big migration, no retraining the whole team. Just one focused service where the tradeoffs make sense.
What I wouldn’t do is rewrite our CRUD APIs in Rust. The database is the bottleneck there, not the language. Go is plenty fast for request routing and JSON shuffling, and the team can iterate on those services without learning a new language.
The staffing question is real too. I can’t hire Rust developers easily right now. If I put Rust into production, I need to be honest that I’m also signing up to teach it. That’s a cost.
Where I’ve landed
Rust is the real deal for specific problems. Memory safety without a GC, predictable performance, genuinely safe concurrency. These aren’t marketing claims – they hold up in practice.
But it’s not a replacement for Go. Not for us, not right now. It’s a complement. A sharp tool for the places where Go’s tradeoffs start to pinch.
I’m going to keep exploring. Probably going to prototype that parser service over the next few weeks and see how it holds up under our actual production load. If the results are as good as my benchmarks suggest, we might have our first Rust service in production by summer.
That feels like the right way to do it. Small, measured, honest about the costs.