Go vs Rust? Choose Go.
"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
Nullpointers, 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.
❤️ Follow me on Twitter and never miss a post again.
💬 Comments available on Hacker News and Reddit.