You already have an account? Log In

Go to Rust: When switching languages is worth the pain in production

Posted on 25.05.2026

Every few years, a programming language quietly graduates from "interesting side project" to "the thing serious infrastructure is being rewritten in." Rust has been on that trajectory for a while, but 2025 was the year it stopped being a curiosity and started showing up in the keynote slides at AWS re:Invent and on the busiest edge network on the planet. For teams running Go in production — the language that used to be the obvious answer for high-throughput services — the question of whether to migrate is suddenly less theoretical.

This piece is not a sales pitch for Rust. It is an attempt to set out, plainly, when a language migration is actually worth the disruption, what the recent evidence from AWS, Cloudflare and others actually tells us, and what Australian engineering teams should think about before booking the rewrite.

The case the hyperscalers are making

At AWS re:Invent, the company gave Rust an unusually prominent spotlight. According to DevClass's coverage, AWS pointed to Rust workloads running roughly 10 times faster than Kotlin equivalents, and crucially for the Go-to-Rust question, delivering around one tenth the latency of comparable Go services in their internal benchmarks.

Cloudflare has been even louder. In a recent post on the company blog titled "Cloudflare just got faster and more secure, powered by Rust", the company describes rewriting core proxy and security components in Rust to improve both performance and memory safety. This is significant because Cloudflare was, for years, one of the most cited large-scale Go shops in the world.

The pattern is consistent: companies that genuinely care about per-request latency at the 99th percentile, memory predictability, and CPU cost at hyperscale are the ones reaching for Rust. That is the honest scope of the argument. It is not "Rust is better." It is "Rust is better for a specific class of problems that mostly involve a lot of nines and a lot of CPUs."

Why teams actually switch — and why Go is usually fine

It is worth saying clearly: most teams running Go today should keep running Go. Go's whole appeal — quick compile times, a small surface area, an opinionated standard library, fast-enough performance — is intact. The same trade-off logic shows up in the wider language debate. A recent tech-insider.org comparison of Go and Python in 2026 measured a 75x CPU gap between the two and a roughly USD $20,000 salary divide for Go specialists. That is the kind of headline number that prompts a migration — until you remember that for most CRUD workloads, Python's CPU "penalty" is irrelevant because the bottleneck is the database.

Rust-from-Go follows the same logic. A team should only seriously consider it when one of the following is true:

CPU cost is a line item that hurts. If you are spending seven figures a year on compute and a 3-5x efficiency gain would pay for the rewrite within 18 months, the maths starts to work.
Tail latency matters commercially. Cloudflare and AWS care because milliseconds shape SLAs and customer churn. A typical SaaS API does not.
Memory safety has bitten you in production. Go is memory-safe in the garbage-collected sense, but data races and subtle concurrency bugs are still common. Rust's borrow checker eliminates an entire category of these at compile time.
You are writing something that should not have a garbage collector at all — a proxy, a database engine, an embedded agent, a kernel module, a cryptographic library.

If none of these apply, the rewrite is almost certainly a vanity project.

The lessons from migrations that have actually happened

One of the more useful recent write-ups is InfoWorld's piece on migrating Python to Rust with Claude. The takeaways generalise neatly to a Go-to-Rust migration, and they are worth absorbing before any team commits.

1. LLMs make the syntactic migration cheap but not the design migration

An AI assistant can mechanically translate Go functions to Rust. What it cannot do is translate idioms. Go's "share memory by communicating" channel patterns do not always map cleanly onto Rust's ownership model. A `sync.WaitGroup` is not a borrow-checked construct. The InfoWorld piece is candid that the line-by-line translation is the easy half; the genuinely hard work is rethinking the data model so the borrow checker is your friend rather than your antagonist.

2. Compile times will hurt your team's morale before they hurt your throughput

Go developers are used to sub-second incremental builds. Rust is not in that ballpark and probably never will be. Plan for it. Workspace structure, codegen units and pragmatic use of dynamic dispatch matter more than they did in Go.

3. The error-handling culture shift is bigger than the syntax

Go's `if err != nil` is verbose but flat. Rust's `Result` with the `?` operator and rich error enums forces a more disciplined approach. Teams that lean into this — defining proper error types per crate, using `thiserror` for libraries and `anyhow` for binaries — get cleaner code than they had in Go. Teams that resist it end up writing Go in Rust syntax, which is the worst of both worlds.

4. Hiring is a real constraint, especially in Australia

The Australian Rust community is enthusiastic but small. Outside Atlassian, Canva, a handful of fintechs and the Sydney/Melbourne crypto-and-infrastructure crowd, finding senior Rust engineers locally is genuinely hard. The pragmatic move for most teams is to upskill existing Go developers — they already think about concurrency, types and performance — rather than hire in. Budget three to six months before someone writes Rust as fluently as they wrote Go.

A migration playbook that does not bet the company

The teams that have migrated successfully share a pattern. They do not rewrite. They replace at the edges.

Identify one hot path. Usually a single service or library that dominates CPU spend or latency. Cloudflare's approach to replacing components rather than rewriting the proxy in one go is the right template.
Wrap, do not rewrite. Expose the new Rust component over a stable interface — gRPC, FFI, or a Unix socket — so the rest of the Go codebase does not need to know.
Measure before, during and after. If you cannot demonstrate a measurable improvement in p99 latency, CPU cost or incident frequency, the migration has failed regardless of how clean the code looks.
Keep Go for everything else. Polyglot infrastructure is normal. The companies championing Rust still run enormous Go fleets.

The honest conclusion

Rust is having a moment because the largest infrastructure operators on earth have decided the per-millisecond and per-watt economics finally justify its learning curve. That is a meaningful signal. It is not, however, a directive. For an Australian team running a profitable Go-based product, the rational move in 2026 is usually to stay on Go, watch the migration patterns emerging from AWS and Cloudflare, and pilot Rust in one well-chosen component where the performance or safety win is unambiguous.

The teams that get burned by language migrations are almost always the ones who switched for fashion. The teams that benefit are the ones who could write you a one-paragraph business case before they wrote a single line of new code. If you cannot write that paragraph yet, the answer to "should we migrate to Rust?" is "not this quarter."