In this post, I'll make an attempt to compare GoLang, Zig, and Rust. And why Rust wins this comparison (for me).
Story Time!
I wrote 3 of my projects in GoLang, Zig & Rust. These projects are sufficiently big to get a good idea about the language fundamentals, shortcomings, and whether there's a problem with the language, the framework, or the ecosystem.
TIP: feel free to jump to TLDR section to just get the damn answer.
GoLang
I started building developer tools a few months back, initially with GoLang.
The first one was a basic database management & migrations utility (dbdaddy) and I genuinely had fun working with GoLang.
Even though this was my very first attempt with GoLang building something more serious than Advent Of Code & 1 billion row challenge problems, I was surprised that it took me less than a week to get proficient at it.
Zig
All this while, I was dabbling with Zig on the side (nothing too serious). I heard about Redis changing their license to a "technically non-open-source" license.
And I thought to myself: how hard can it be to build a new open-source redis in zig?
Fast-Forward 2 months later: damn.
The basic idea behind "GbCache" was an LRU-based in-memory cache but the actual source of truth was to be saved on disk along with features like notifications for specific key/value changes caused and obviously TTLs assigned to keys.
It is impressive how explicit Zig is, which makes it all the more simple and easier to work with.
I started GbCache from the perspective of "if it were to go HyperScale™ tomorrow, can it handle the load?"
This perspective drove me to rule out GoLang because if I am unable to reason with extreme certainty about the memory allocations, I won't have complete control over the speed.
Doing things from this perspective is a really great learning experience because suddenly you start seeing all the points in your program that might blow up, run out of memory or may become a bottleneck —the hot paths in your code.
Due to Zig's explicitness, I was sure of exactly where & when I am allocating memory.
But... Zig is NOT a memory-safe language at the end of the day and I am a guy with skill issues the size of Everest.
enters rust
In the last 2 years, I've tried and rage-quit on Rust 3 times. Coming from a JavaScript background where we have a bajillion gb ram in our macbook m69 maxes, I never really understood why Rust had those rules, and going in with the hype was probably a bad angle to look at it from.
Even though I rage-quit several times, Rust was still in the back of my mind, its weird syntax, frustrating memory rules, and mind-boggling lifetimes.
But something hit me while writing Zig... I already was keeping track of all these memory rules and lifetimes but as a mental overhead.
I started noticing patterns and boilerplate in my Zig code trying to do what Rust already does.
Rust
While building the CLI client for SFS (SFW name - "Simple File Storage") I decided to give Rust another try.
This time around while going through the rust book, I started to feel the "why" of it all.
The most fundamental thing that I love about Rust is the ownership & borrowing-based mental model of memory.
Even though this model of owned & referenced memory is imaginary, it is a convenient mental model to reason about and incurs less overhead over my head.
As opposed to the classic mental memory model that languages like C & Zig incur on your head. Have to track individual memory allocations & their lifetimes in my head? no thanks!
TLDR
GoLang
- FAST (like your 5 MAUs are gonna need it lmao)
- reliable
- stupid simple, language is never standing between you & your goal
- great ecosystem of packages
Zig
- BLAZING FAST
- stupid simple
Rust
- BLAZING FAST
- reliable
- great ecosystem of packages
All Of Them
- amazing error handling
If you're an everyday normal mo— backend engineer and like doing numbers on their sprint performance, your best choice is probably GoLang.
"but my company doesn't use GoLa—"
"leave the company, leave it, use the right job for the tool. leave the company."
To me, GoLang is like an arranged marriage where you never feel that rush in your heart but it never lets you down, it's your ride-or-die companion and you can bet your whole life on it.
But my friend if you are looking for that rush keep reading on!
Rust Puran
bu— but i want that rush... i want to feel my heart explode on catching a mere glance at their ey-syntax... i want to feel like i am in heaven when I'm with them and in hell when I'm not...
Let's have a quick look at an example of multi-threaded safety in Rust.
use std::thread;
fn main() {
let mut counter = Box::new(0); // 32-bit integer allocated on the heap
let mut handles = vec![];
for _ in 0..10 {
let handle = thread::spawn(|| {
*counter += 1; // trying to edit the value
});
handles.push(handle);
}
for handle in handles {
handle.join().unwrap(); // WAITING FOR ALL THE THREADS TO COMPLETE
}
println!("Result: {}", *counter);
}
We have a heap-allocated value and there are 10 threads trying to modify it independently.
This code is unsafely accessing the counter variable as all the threads will try to modify counter simultaneously.
In other languages, similar code will happily compile and run.
If you have worked in a multithreaded environment before, your first thought might be to use a "mutex" to prevent race conditions in updating the counter variable.
But it's easy to miss little things like this in a big codebase due to human error.
Rust won't even let this program compile.
Due to ownership & borrowing rules, the compiler will detect that you are mutably borrowing counter in the first thread in the first iteration of the for loop... ok until now... the second iteration also wants to mutably borrow counter parallelly? unsafe! raise a COMPILE-TIME ERROR!!.
referencing or "borrowing" a value from its owner with the intention of mutating/modifying is called a "mutable borrow"
src/main.rs|8 col 36-38 error| cannot borrow `*counter` as mutable more than once at a time `*counter` was mutably borrowed here in the previous iteration of the loop
In situations like these, other languages don't give you any error at all. It's your responsibility to inspect the correctness, Rust prevents that.
Constructs like these spread across the language help you to not shoot yourself in the foot (often).
Conclusion
IT DEPENDS!
I really wish there were a language that was the answer and even if GoLang comes pretty close to that, it really depends on your use case and most importantly, your team.
for me, Rust is a pleasure to work with (for now, who knows... hehe)
folks at TigerBeetle took a chance on Zig and they're happy with it.
Primeagen is happier with Zig.
for Jarred Sumner, Zig is fine, he wrote Bun in Zig.
Mitchell Hashimoto (guy behind HashiCorp) is writing ghostty in Zig, a BLAZING FAST termin—
.
.
.
wait...
Top comments (0)