Ask HN: Is Go or Rust a more viable language to learn in 2017? | Hacker News Reader

Ask HN: Is Go or Rust a more viable language to learn in 2017?

7 pointsharrylucas7 comments

I have a read a heap of articles outlining inherent problems with Golang (https://github.com/ksimka/go-is-not-good), but the problem is you can find people complaining about every language if you type the right thing in google.

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)

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, 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.

> 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.)

     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.

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).

Agree 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.

If you need the kinds of things Rust can provide, then it's a very good choice.

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.

If you are trying to make a decision for "from scratch" usage (rather than to find a job), then I'd go with Rust. The main problem is its potentially steep learning curve, which could easily mean not many developers can pick it up.

I would say rust, but in 2016 other than operating systems and maybe a few other select areas i dont really want to do manual memory management, GC me baby. I would say go but I don't really want to use a language that leaves about everything else good out even though it has a GC.

Reply on news.ycombinator.com