3 ms·
Given your criteria Go wins easily although HN is a little bit of echo chamber of Rust enthusiasts and Go haters, so you want necessarily get balanced opinion h
by kjksf 10y ago
Given your criteria Go wins easily although HN is a little bit of echo chamber of Rust enthusiasts and Go haters, so you want necessarily get balanced opinion here.
Here's how Go stacks up compared to Rust on axis that I consider important.
1. Jobs: plenty of jobs in Go (and growing rapidly), almost no jobs with Rust. For example, on https://angel.co https://angel.co, there are 67 companies in California with Go jobs (60 with "Golang" skill filter and 7 with "Go" skill filter) and 0 with Rust jobs. Every month in "Who's hiring" thread on HN the same thing: a fair amount of Go jobs, next to nothing of Rust jobs.
I predict number of Go jobs will be growing quickly for some time to come.
2. Go: easy to learn. Rust: hard to learn.
3. Go: GC makes memory management easy. Rust: manual memory management and rust-specific for even bigger barrier to entry.
4. Go: fast to compile. Rust: slow to compile. That contributes to programmer productivity.
5. Go: both language and fundamental libraries (networking, concurrency, json, xml, databases etc.) are mature and stable.
Rust: language is still evolving. Ecosystem of fundamental libraries is sometimes lacking important stuff, has too many options (which of 3 json libraries should I use) or options are still not mature.
6. Go: large and growing list of tools, both shipped as part of Go and made by community (debuggers, memory and cpu profilers, race detector, runtime tracing for debugging multi-threading).
Rust: not so much.
7. Go: a large number of important code-bases are written in Go, proving that it's suitable for large scale software (docker, kubernetes, prometheus, influxdb, tidb, cockroachdb - those are from memory.
Rust: mozilla is dabbling with using Rust for FireFox but I don't know any large project that went full Rust.
8. Go: used by tens of companies you've heard about (https://quicknotes.io/n/1XB0 https://quicknotes.io/n/1XB0).
Rust: the equivalent list for rust will be at least 10x smaller.
At the end of the day proof is in the pudding.
Go is easily winning by pretty much any metric that is not based on opinion. Language X is better than Y is an opinion. Language X has more jobs, more libraries, compiles faster, is used by more companies etc. is not an opinion, it is the pudding.
- stuxnet79 10y agoAgree with everything here. I've been passively looking for a new position and I've been surprised with the amount of companies looking for devs familiar with GoLang. That's all the evidence I needed to start familiarizing myself with it. I even joined a local Go Meetup group.
- dbaupp 10y ago> Rust: language is still evolving. The language has been at 1.0 and hence backwards-compatibility for a year and a half. Features are being added, but existing code is stable now, with a similar (or maybe even more strict) compatibility promise to the one Go has. > 6. Go: large and growing list of tools, both shipped as part of Go and made by community (debuggers, memory and cpu profilers, race detector, runtime tracing for debugging multi-threading). > Rust: not so much. This is wrong: Rust can use all the same tooling as C and C++, and they work well. This includes debuggers like gdb and lldb (and, even better, rr), as well as profilers/other things like perf and valgrind. The situation may be a little misleading because Rust doesn't have to reimplement everything like Go, and, furthermore, I don't think having to duplicate work is a good thing. Additionally, the language itself helps mitigate a lot of bugs for which such tooling is needed. Strong assurances and more automated checking are the pay off of the steeper learning curve and "manual" memory management. (Of course, as you imply, having the compiler be more helpful may not be worth the trade-off for a domain like web apps/microservices.)
- runT1ME 10y agoa large number of important code-bases are written in Go, proving that it's suitable for large scale software (docker, kubernetes, prometheus, influxdb, tidb, cockroachdb - those are from memory. Given some of the issues we've seen in the quality of the above mentioned software, I wouldn't be surprised if in the next couple years we see a lot of regret for being so gung-ho over Go (ala PHP in the early 2000s).