Why I'm Learning Rust in 2022 (as a Go Developer)

TL;DR — Rust earns its complexity in three places: memory-safe systems work without a GC, performance-critical backend APIs where every microsecond matters, and shared-state code where the borrow checker outperforms test discipline. For everything else, Go is still the right tool. I’m learning Rust to grow into the first three.

February closed the Postgres + CI/CD theme. March pivots hard: I’m spending the next month learning Rust, specifically through the lens of backend APIs. This first post is the “why” — what made me pick it up, what I expect to get out of it, and what I’m explicitly not expecting.

If you’re a Go developer in 2022 wondering whether to bother with Rust, this is the post I wish someone had written for me three months ago.

The Go developer’s case for Rust

I’ve been writing Go since 2016. Three of January’s services shipped in Go. I will keep writing Go for most of what I do. Rust is not a replacement; it’s a tool for a different shape of problem.

Three concrete things Rust does that Go genuinely can’t:

1. Memory safety without a GC. Go’s GC is excellent for almost everything. The “almost” matters. For low-latency systems — game servers, trading systems, embedded, edge proxies — even a 100 µs GC pause is noticeable. Rust’s compile-time memory management eliminates the GC entirely and the latency profile that comes with it.

2. Predictable, top-tier performance. Go is fast. Rust is often 1.5–3× faster on the same workload, more on CPU-bound code. For a CLI tool, this doesn’t matter. For a service serving 50K req/s where 30% of compute is JSON parsing, halving the parse cost is real money.

3. The borrow checker catches what tests don’t. Go has data races. Lots of them. The race detector finds them at runtime if your tests happen to exercise the code path with the race. Rust makes most data races impossible to compile. The cost is a steep learning curve. The benefit is a class of bugs you simply stop having.

That’s the tradeoff. Rust costs more upfront. It buys things Go can’t sell.

What I’m not expecting Rust to do

The other side of the honesty. Rust will not:

• Make me ship faster. It will make me ship slower for the first six months, probably longer. The compile times alone halve my iteration rate compared to Go.
• Replace Go for me. I’ll use Rust for the 15–20% of work where it earns its complexity, Go for the rest. Two tools, two jobs.
• Be the right call for a small team’s first backend language. Go’s lower ceiling is a feature when you’re hiring. Rust’s higher ceiling demands more from every contributor.
• Fix bad architecture. The borrow checker catches memory bugs. It doesn’t catch a service boundary that shouldn’t exist. You can write spaghetti in any language.

If your motivation for Rust is “Go feels too simple,” go back to your job and ship something. If your motivation is “I have a specific perf or correctness problem Go can’t solve cleanly,” welcome aboard.

What this month covers

March’s posts walk through the things I’ve learned in my first month with Rust as a backend developer:

• Mar 4: Ownership and borrowing — the central concept, explained for people who already understand pointers
• Mar 7: Lifetimes — the part of Rust that scares everyone, demystified
• Mar 9: Error handling — Result, ?, thiserror, anyhow
• Mar 11: Cargo workspaces — project layout for a real service
• Mar 14: Async Rust with Tokio — what async actually compiles to and how to think about it
• Mar 16: Axum for JSON APIs — building a real HTTP service
• Mar 18: Postgres with sqlx — the database layer
• Mar 21: Serde patterns — JSON that doesn’t fight you
• Mar 23: Structured logging with tracing — the observability layer
• Mar 25: Containerizing Rust — sub-25 MB production images
• Mar 28: Rust vs Go for backends — honest side-by-side
• Mar 30: Month retro — what stuck, what didn’t

By the end you should have enough working code to evaluate whether Rust earns its keep in your shop.

What 2022 changed for Rust

Five years ago I tried Rust and gave up. Compile times were brutal, the ecosystem was thin, async was a research project. In 2022 the ground has shifted enough to be worth a second look.

Stable, mature async. async/await landed in stable Rust at the end of 2019 and the ecosystem has had two-plus years to settle. Tokio 1.x is the de facto runtime. Axum (released by the Tokio team in 2021) and the Actix-web 4 release (Feb 25, 2022) are both solid choices for HTTP services.

The Cargo ecosystem caught up. sqlx, serde, tracing, reqwest, tower — the libraries you need for backend work are in place, are maintained, and play nicely together.

Edition 2021 cleaned up rough edges. Closure capture rules, panic! macro consistency, IntoIterator for arrays. Small things, but it signals that the language is iterating on ergonomics rather than just adding features.

Compile times got tolerable. Still slow. Less brutal than they were. Incremental compilation works. cargo check is fast enough for inner-loop dev. The 30-second cold compile is still a thing, but it’s not the 5-minute one it used to be.

Major adopters in production. Cloudflare, AWS (Firecracker, S3 components), Discord, Figma, Microsoft (Azure components), Dropbox, Mozilla. Not “tinkerer’s language” anymore. Hiring is realistic.

What still hurts

Honesty continued. Things that suck about Rust in March 2022:

• Compile times are slow. Even with incremental builds, the first build of a non-trivial workspace is several minutes. CI feedback is the worst part of the experience.
• async is two languages glued together. Sync Rust and async Rust have different rules and the boundary is awkward.
• The borrow checker WILL fight you for the first weeks. The fight is winnable, but expect it.
• Lifetime annotations look like noise until they don’t. They will look like noise for longer than you’d like.
• The standard library is intentionally minimal. You will pull in dependencies for things Go ships in stdlib. serde_json, tokio, reqwest, tracing — all crates, all standard, none in std.

Knowing the rough edges up front is the difference between “I tried Rust and bounced” and “I learned Rust and shipped.”

A reading recommendation, since people will ask

The Rust Book (doc.rust-lang.org/book/) is the canonical resource. It’s also where I’d start. After that, the resources I leaned on hardest:

• Rust by Example (doc.rust-lang.org/rust-by-example/) — same shape as the Book but code-first
• Jon Gjengset’s YouTube channel — for deep dives on specific topics like async or lifetimes
• The Rustonomicon (doc.rust-lang.org/nomicon/) — only when you start writing unsafe; ignore at first

Library-specific docs are good. tokio.rs and the Axum repo’s README are both excellent.

Wrapping Up

I’m picking up Rust because three real production problems I have right now don’t have clean answers in Go. Memory-safe systems work, predictable low-latency backends, and shared-state correctness. None of those are urgent enough to bet a service on day one — but they’re real enough to spend a month learning. Friday: ownership and borrowing, translated for a Go developer who already knows pointers.