Rust vs Go vs Zig: What the Benchmarks Don't Tell You

Look, benchmarks are bullshit. They tell you how fast your code runs in a perfect world with synthetic workloads. They don't tell you how long you'll spend fighting the language to make it do what you want.

Rust: Fast Code, Slow Developer

Rust's borrow checker is like having a really smart, really pedantic coworker looking over your shoulder. Every time you try to do something slightly clever, it tells you why you're wrong. And it's usually right, which makes it worse.

The error messages are actually pretty good once you learn to read them:

error[E0502]: cannot borrow `data` as mutable because it is also borrowed as immutable

But "good" doesn't mean "obvious." I probably hit this error fifty times before I understood what the hell it was trying to tell me. Solution was usually to clone stuff or restructure the code completely.

Async Rust is where things get really fun. You want to share some state between tasks? Cool, now you need Arc<Mutex>. Or maybe Arc<RwLock>. Or tokio::sync::RwLock. Good luck figuring out which one. The compiler will tell you when you're wrong, but not which one is right.

Go: Boring is Beautiful (Until GC Strikes)

Go compiles stupid fast. Like, blink and you miss it fast. Writing Go feels like using a Honda Civic - not exciting, but reliable and gets you where you need to go.

Then you hit production and realize the garbage collector is a real thing that actually pauses your program. Our latency graphs looked like a heart monitor. Every few seconds, boom, 200ms spike because GC decided it was cleaning time.

You can tune it, set GOGC=50 or whatever, but honestly most of the time you just live with it. Or you write your code differently to generate less garbage. Which is annoying but doable.

The race detector is legitimately amazing though:

WARNING: DATA RACE
Read at 0x00c000102040 by goroutine 7:
  main.handleRequest()

Just run your tests with -race and it'll catch the concurrency bugs you didn't know you had. Found a map we forgot to lock. Would've been impossible to debug otherwise.

Zig: When C Doesn't Hate You (Much)

Zig feels like C if C wasn't trying to hurt you. The comptime stuff is actually pretty cool - you can run code during compilation which is wild if you think about it. But it's not even 1.0 yet, so expect things to break.

Had a segfault in production once:

fish: Job 1, './server' terminated by signal SIGSEGV (Address boundary error)

Turns out I messed up memory management. Shocking, I know. But at least Zig gave me a decent stack trace when I compiled with debug info. In C this would've been a nightmare to track down.

Compilation is usually fast, but sometimes the linker decides to take a coffee break. Seems to be a Linux thing - works fine on Mac. Cross-compilation is supposed to be great but I haven't had much luck with it.

Performance though? Really damn fast. No GC pauses, no borrow checker fights, just native code doing native code things. Used way less memory than the Go version too.

Look, I've used all three for actual projects. Not toy examples, not hello world servers, but real systems that people depend on. Here's what I learned.

The Discord Thing Everyone Talks About

Yeah, Discord switched from Go to Rust for one specific service. Everyone acts like this proves Rust is better. What they don't mention is Discord tried optimizing the Go version first and got most of the way there with some clever caching and data structure tweaks.

The Rust rewrite wasn't magic - it just eliminated lock contention that was killing their Go performance. Could they have fixed the Go version? Probably. But once you're on the Rust rewrite train, it's easier to keep going than admit you might have been able to fix the original.

The real story isn't "Rust is 10x faster." It's "sometimes a rewrite lets you fix architectural problems you couldn't fix in the original."

Go: The Boring Choice That Actually Works

Kubernetes, Docker, Terraform - they're not written in Go because Go is the fastest language. They're written in Go because you can hire people who can maintain them without wanting to quit.

I've built Go services that handle plenty of traffic. Not because Go is magic, but because Go is predictably okay. GC pauses suck, but they suck in a predictable way. You can tune around them or just accept that your 99th percentile latency isn't going to be perfect.

Go services are stable. Rust services are faster but sometimes have weird performance cliffs. Zig services are fast as hell until they crash and take everything down with them.

Zig: C for People Who Don't Hate Themselves

Zig has some cool ideas. Comptime is neat. Cross-compilation actually works most of the time. The allocator system makes sense if you've been burned by malloc/free.

But it's not 1.0 yet and you can feel it. I've hit compiler bugs that only show up in release builds. Debug works fine, release corrupts memory. Fun times.

For embedded stuff, Zig is actually pretty great. Caught some buffer overflows that C would've let slip through. Smaller binaries, better error messages.

For web services? I wouldn't. Maybe after 1.0 ships and gets some battle testing. Right now it's too unstable for anything you actually depend on.

Team Reality Check: Productivity Matters More Than Performance

Most performance problems aren't language problems - they're architecture problems. I've seen Python services outperform Rust services because the Python team actually knew their database. I've seen Go services handle more load than C++ because they used proper caching instead of trying to optimize everything by hand.

Language choice matters less than:

• Can your team debug it when things break?
• Can you hire people who know it?
• Does the ecosystem have what you need?
• Can you ship features fast enough?

Use Rust when you need maximum performance and correctness, and you have experienced developers who won't quit. Use Go when you need to ship features and hire people. Use Zig when you're building systems software and don't mind some instability.

Everything else is just benchmarketing.