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 (12)
Not sure bro, I feel your list is missing Gleam
How was your experience with it? I’ve been procrastinating on trying it…
Enjoyed your article! It was refreshing that you stated your favorite in the second sentence, rather than telling the reader they had to read everything to find out.
Glad that you liked it!
I stopped learning rust after 1 month fcking learn haha 😂😂😂 i think gokag is enough for me
Golang is enough for most people hahaha
For me only JS + Python. Golang is still in the back of my mind, but never got a chance to give it a serious try though.
Why not give it a try this weekend?
Go is great until you want to do metaprogramming (templates) - and then you're forced to copy paste. Overall, it's a pretty decent language, it's just clunky in this regard.
What do you mean by templates here? Go's templating engine is really strong afaik, it is the base of the hugo static site generator. Hugo is the best right now unless you want to make everything in html/css/js, and it's miles better than jekyll (the previous "standard").
Do you mean something completely different?
Loved the article!
I started learning a bit of Zig yesterday, and I'm planning to give it s try to Rust in the future.
Do you have any suggestions on learning material?
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more