Go vs Rust? Choose Go.
Published on 15th of September 2017
"Rust or Go, which one should I choose?" is a question I get quite often.
My answer is simple: use Go.
Not because Go is the better language,
but because people want a simple answer to a (seemingly) simple question.
Both languages seem to be competing for the same user base and they both seem to be
"systems programming" languages, so there must be a winner, right?
Here's the thing: if you choose Rust, usually you need the guarantees, that the language provides:
- Safety against
Null pointers, race conditions and all sorts of low-level threats.
- Predictable runtime behavior (zero cost abstractions and no garbage collector).
- (Almost) total control over the hardware (memory layout, processor features).
- Seamless interoperability with other languages.
If you don't require any of these features, Rust might be a poor choice for your next project.
That's because these guarantees come with a cost: ramp-up time.
You'll need to unlearn bad habits and learn new concepts.
Chances are, you will fight with the borrow checker a lot when you start out.
With Go, you get things done fast.
Go is one of the most productive languages I've ever worked with.
The mantra is: solve real problems today.
I don't think Go is an elegant language. Its biggest feature is simplicity.
Go is not even a systems programming language. While it's great for writing microservices and tooling around backend infrastructure, I would not want to write a kernel or a memory allocator with it.
Rust in comparison is hard. It took me many months to become somewhat productive.
You need to invest a serious amount of time to see any benefit.
Rust is already a powerful language and it gets stronger every day.
It feels much more like a "pragmatic Haskell" to me than a "safer C".
99% of the time, Go is "good enough" and that 1% where it isn't, you'll know.
And then take a look at Rust, because the two languages complement each other pretty well.