Ask HN: Is Go or Rust a more viable language to learn in 2017?
What I am confused about is that if it has all these problems, how come it has risen to one of the most popular languages (http://www.tiobe.com/tiobe-index/) jumping 34 positions since 2015.
Rust on the other hand was voted the most beloved language http://stackoverflow.com/research/developer-survey-2016#technology-most-loved-dreaded-and-wanted . And everyone seems to be saying it's much better then go.
Now obviously they aren't the same language and will be used for the same things, however from my understanding, they CAN be used to achieve similar things.
So basically, if I wanted to build tools/optimizations for web applications (not the whole application it's self) e.g. microservices, custom parsing libraries etc, which one would be best going forward?
Taking into account:
1. Community (e.g. available packages, friendliness)
2. Growth (e.g. how much either is growing)
3. Future outlook (e.g. bust out your crystal balls)
4. Productivity
5. Developer happiness (e.g. who wants to be miserable)
7 comments
[ 3.2 ms ] story [ 23.4 ms ] threadHere'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, 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).
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.
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.)
However, if you decide Go fits your needs better, in the sense that you want a garbage collected language, then I can't think of any reason to use Go over plenty of better options.