Rust vs Go in 2026: We Rewrote 3 Services and Regretted 1

General
1

I want to share a real story from our financial services company about choosing Rust vs Go, complete with actual numbers and one decision we regretted.

The Context

We’re a major financial services company with 40+ engineers. Last year, our cloud bill hit k/month and we identified a problem: 3 microservices were consuming 80% of our compute budget. These services handled high-frequency trading calculations, real-time fraud detection, and payment processing—all CPU and memory intensive.

The Decision: Rewrite in Rust

We chose Rust for these reasons:

  • Memory usage was our primary bottleneck
  • Security audit requirements (financial services = heavily regulated)
  • Performance predictability (GC pauses in Go were causing issues)

The Implementation

  • Timeline: 6 months
  • Team: 3 dedicated engineers (2 senior, 1 mid-level)
  • Original language: Go
  • Migration approach: Service by service, with parallel running during validation

The Results

After migration:

High-frequency trading service:

  • Memory usage: Down 65% (12GB → 4GB)
  • Latency P99: Improved 40% (45ms → 27ms)
  • Monthly cost: k → k

Fraud detection service:

  • Memory usage: Down 58% (8GB → 3.5GB)
  • Throughput: Up 35%
  • Monthly cost: k → k

Payment processing service:

  • Memory usage: Down 48% (6GB → 3GB)
  • Latency P99: Improved 22%
  • Monthly cost: k → k

Total savings: k per month in cloud costs.

But Here’s What They Don’t Tell You

Feature velocity on these three services dropped 40%. Tasks that took 2 days in Go now take 3-4 days in Rust. Why?

  1. Borrowing and lifetimes: Fighting the compiler takes time, especially for mid-level engineers
  2. Ecosystem gaps: Some libraries we needed didn’t have Rust equivalents, had to write wrappers
  3. Hiring challenge: Finding Rust engineers takes 2-3x longer than Go engineers
  4. Code review slowdown: Fewer engineers comfortable reviewing Rust PRs

The One We Regretted

Payment processing service—we shouldn’t have rewritten it in Rust. Yes, we saved money, but the real bottleneck wasn’t CPU or memory, it was network I/O to our bank APIs. The performance improvement was minimal compared to the development velocity hit.

We should have kept it in Go and invested in better caching or a CDN. The ROI wasn’t there.

The Framework We Should Have Used

Ask yourself:

  1. What’s the actual bottleneck? CPU/memory = consider Rust. I/O bound = stay with Go.
  2. What’s more expensive: cloud costs or engineering time? In our case, for 2 of the 3 services, cloud costs won. For the third, engineering time should have won.
  3. What’s the hiring pipeline? If you can’t hire or train Rust engineers, it doesn’t matter how much money you save.
  4. What’s the opportunity cost? Those 6 months of rewriting = 6 months not building new features.

The Lesson

Rust isn’t always the answer, even when performance matters. Calculate the real break-even point:

  • Engineering time cost: 3 engineers × 6 months × k salary = k
  • Cloud savings: k/month
  • Break-even: 2.5 months

But that doesn’t account for ongoing velocity loss. We’re still living with slower development on those services.

When We’d Choose Rust Again

  • Security-critical components with clear performance bottlenecks
  • Long-running services where optimization pays off over years
  • When we have Rust expertise in-house already

When We’d Choose Go

  • I/O-bound services (which is most web services)
  • Rapid prototyping and MVP development
  • When team velocity matters more than compute efficiency

Question for the Community

How do you calculate the ROI of performance optimization vs development velocity? What’s your framework for making this trade-off?

2

Luis, this is incredibly valuable data. Thank you for sharing the numbers—most people only share the success stories, not the regrets.

EdTech Perspective: We Almost Made the Same Mistake

At my EdTech startup, we were considering Rust for our video transcoding service last year. The math looked similar to yours:

  • Cloud costs: k/month for transcoding
  • Estimated savings with Rust: 50-60%
  • Potential savings: -20k/month

We almost pulled the trigger. But then I looked at the hiring side of the equation.

The Hiring Reality

Time to fill positions (our actual data from 2025):

  • Go engineer: 45 days average
  • TypeScript engineer: 38 days average
  • Rust engineer: 127 days average (yes, really)

And the salary premium: Rust engineers were asking 20-30% more than Go engineers with equivalent experience levels.

We Chose Go

Instead of rewriting in Rust, we:

  1. Optimized our Go code (found some obvious inefficiencies)
  2. Implemented better caching
  3. Moved transcoding to spot instances
  4. Added a CDN for processed videos

Result: Brought the bill down to k/month without a rewrite and without the hiring constraints.

When I Would Choose Rust

Your framework resonates. For us, I’d choose Rust when:

  1. Security-critical and isolated: Auth tokens, encryption, payment tokenization—small, focused services where security matters more than feature velocity

  2. Clear long-term ROI: If we’re building something that will run for 5+ years and the performance gain pays for itself repeatedly

  3. Existing expertise: If we already have Rust engineers who can mentor others

The Constraint Nobody Talks About

The real constraint isn’t technical—it’s organizational. Can your team sustain the knowledge transfer? In a 40-person team, you can probably maintain expertise in 2-3 languages max. For us, that’s TypeScript, Go, and Swift/Kotlin for mobile. Adding Rust would mean one language doesn’t get the attention it needs.

Question for You

How do you handle knowledge distribution? Do those 3 Rust services become “owned” by the engineers who wrote them? That feels like a bus factor problem waiting to happen.

3

Coming from the security side, I want to add a dimension that might justify your Rust rewrites beyond just performance: memory safety as a security property.

The Identity Verification Perspective

At my fintech, we rewrote our identity verification service from Go to Rust 18 months ago. Not primarily for performance—for security.

The service handles:

  • Social security numbers
  • Driver’s licenses
  • Passport scans
  • Biometric data

In Go, we had two memory-related vulnerabilities discovered during security audits:

  1. A data leak where sensitive data wasn’t properly zeroed after processing
  2. A potential buffer overflow in image processing (we used a C library via CGo)

Rust’s ownership system and memory safety guarantees eliminated this entire class of vulnerabilities.

But Trade-offs Still Apply

Your point about velocity is spot on. Our Rust identity service:

  • Features take 30% longer to implement
  • Code reviews are more thorough (good!) but slower (bad!)
  • We have 2 engineers who can work on it confidently, 5 others struggle

When Memory Safety Justifies the Cost

For us, Rust makes sense when:

  1. Handling sensitive data: PII, financial data, credentials
  2. Attack surface: Public-facing APIs that process untrusted input
  3. Long-running processes: Services that run for months without restart

For business logic services that don’t touch sensitive data? Go is fine. Most security issues are logic errors (authorization checks, rate limiting, input validation), not memory corruption.

Real Example

We had a fraud detection algorithm that we considered writing in Rust. The data it processes is already sanitized and encrypted. The real security concerns were:

  • Is the algorithm correct?
  • Are the alert thresholds right?
  • Is it auditable?

Memory safety wasn’t the threat model. We kept it in Go because data science iteration speed mattered more.

To Your Framework

I’d add a fourth question: What’s the security threat model? If memory safety is part of your security requirements (financial services, healthcare, government), Rust might be worth it regardless of performance. If not, optimize for velocity.

4

Front-end developer perspective here: I don’t really care if the backend is in Rust or Go, but I care deeply about the impact on API stability and front-end team velocity.

The Hidden Cost of Backend Rewrites

When our backend team rewrote a major service from Node.js to Go two years ago (not even Rust!), here’s what happened to the front-end:

  • API breaking changes (twice): During the rewrite, they changed response formats “to make it more idiomatic Go.” We had to update 30+ components.

  • Feature freeze (4 months): While they focused on the rewrite, no new API endpoints. Our roadmap stalled.

  • Performance regression (temporary): The first version of the Go service was actually slower than Node.js because they were still learning optimization patterns. Took 2 months to get it right.

What I Wish Backend Teams Considered

Before you rewrite for performance:

  1. Profile from the user’s perspective: That 40% latency improvement—did users notice? If the page already loaded in 1.2 seconds, going to 0.9 seconds doesn’t move any product metrics.

  2. API contract stability: Can you guarantee no breaking changes? Or at least a long migration window with both old and new endpoints?

  3. Feature velocity impact: Those 6 months of backend rewrite—what features didn’t ship? What was the opportunity cost?

When I’m Happy About Backend Rewrites

Real story: We had a search API that was taking 3-5 seconds. Users were literally walking away. Backend team rewrote it (Go → Rust with better algorithms), got it down to 200ms.

Result: Search usage up 40%, customer satisfaction scores improved, conversion rate up.

That was worth it. The language didn’t matter—the user-facing improvement did.

Controversial Opinion

Most backend performance optimization should start with:

  1. Better caching
  2. Database query optimization
  3. CDN configuration
  4. Smarter API design (pagination, lazy loading)

Only after exhausting those options should you consider rewriting in a “faster” language.

Question

Why not a hybrid approach? Keep the payment processing service in Go (for velocity), rewrite just the fraud detection and trading services in Rust (where performance truly matters)? Or is that what you ended up doing?

5

Mobile engineer perspective: this debate feels so familiar because we deal with this constantly—native vs cross-platform, and now Rust for shared business logic.

Mobile Faces the Same Bottleneck Question

At Uber, we have services in multiple languages:

  • Go: API gateways, most business logic
  • Rust: Image processing, video encoding, real-time location services
  • Java: Legacy systems
  • Kotlin/Swift: Mobile apps

The decision tree is similar to yours:

When we use Rust on mobile:

  1. Battery-sensitive operations: Video encoding, image compression, heavy computation. Rust’s efficiency = less battery drain.

  2. Shared business logic: Fare calculation, routing algorithms—we compile Rust to both iOS and Android instead of maintaining two implementations.

  3. Performance-critical paths: Real-time location updates, map rendering.

When we DON’T use Rust:

  • UI code (Swift/Kotlin are better for platform integration)
  • API integrations (Go is perfectly fine and faster to develop)
  • Experimental features (need iteration speed)

Mobile Developers Don’t Care About Backend Language

Honestly, from a mobile perspective, I care about:

  1. API latency: Is it fast enough for a good mobile experience?
  2. Bandwidth efficiency: Mobile users are on flaky networks
  3. API stability: Breaking changes are painful for mobile apps (can’t force upgrades)
  4. Battery impact: Efficient backends = fewer API calls = better battery life

Your 40% latency improvement on the trading service? Probably imperceptible to users unless they were already complaining about speed. Mobile apps add their own latency (network, rendering, user interaction).

Profile First, Optimize Bottlenecks

At Uber, we profile the entire stack:

  • Mobile app rendering time
  • Network latency
  • Backend processing time
  • Database queries

Often the bottleneck is network or database, not CPU. Rewriting Go to Rust doesn’t help if the bottleneck is a 200ms database query.

Recommendation

For your payment processing service that you regret: you identified the real bottleneck (I/O). That’s the lesson—always profile before optimizing.

Rust is amazing for CPU-bound problems. But most web services are I/O-bound. Know which problem you’re solving.