Maybe it's just because Go has Google backing it, but I seem to hear way more about Go than I do about Rust. I have my doubts about whether Rust will have a viable ecosystem in 4-5 years. It's a shame because Rust seems like a more interesting language to me.
Rust is currently backed by Mozilla, Samsung, and an expanding coalition of startups. There are other large companies experimenting with Rust at the moment, but I'd rather wait for them to come out with their own announcements. The community is hugely active and growing at an increasing rate. There are four Rust books in the publishing pipeline and Rust's first conference will be held this year, with at least two conferences already planning for next year. I wouldn't worry about the state of Rust's ecosystem in five years. :)
It might also have something to do with the fact that Go has been out for five years and Rust 1.0 happened two weeks ago, or the fact that you are hearing about Go in different contexts from Rust because the two languages, despite HN's insistence to the contrary, aren't really appropriate for the same use cases.
Are there any good articles comparing the two? What are some contexts where one might be more appropriate than the other? I know Go's special focus is on concurrency. Is Rust less-good for concurrent applications?
Rust is best viewed as a replacement for C++ in performance-critical, security-critical applications that are either resource-intensive, or exist in a resource-starved environment. In particular, it eschews garbage collection while preserving memory safety, even in the presence of multiple threads, something C++ does not. It also has native, overhead-free FFI-level compatibility with C. An example of where Rust is appropriate would be an operating system kernel, a video game, a web browser (writing one, not writing code that runs within one), embedded development, a high-performance database (there aren't any existing examples yet but it strikes me as an ideal language for this purpose), or fast, native extensions to applications written in higher level languages.
Go is a relatively fast, ahead-of-time compiled, garbage-collected language; a good comparable for when you might want to use it would be OCaml (if you don't need threads) or Haskell (if you do). Java (particularly early versions of Java) or C# would also be a good comparable, in circumstances where you don't care about the JIT. Like Haskell, Go also has very good support for M:N threads, a particular threading model optimized for fast context switching and programmer ease of use (a common requirement for socket web servers). Unlike many ahead-of-time compiled languages, it also has compiler performance as an overriding concern--Go prides itself on its quick compilation.
I would not say Go is better than Rust at concurrency. While Rust used to have M:N threads as well, it abandoned them because they turned out to have unacceptable performance tradeoffs in a language without a heavy runtime and garbage collector, and also play poorly with native code not managed by the runtime. Personally, I also feel that safe concurrency is considerably easier in Rust, where common Go idioms like channels are guaranteed to be memory safe, which they are not in Go with GOMAXPROCS > 1, and where it's impossible to see data races through things like mutexes or lockless data parallel threads in safe code.
The reason to use Go over Rust would be that you can afford a garbage collector and a relatively heavy runtime, and are willing to accept some chance of data races (or don't require concurrency at all, or have a particular concurrent application where by far your biggest cost is context switching and you do very little allocation). This is the case for a large percentage of applications. Of course, there are many other languages available under these circumstances as well. I am not personally sure why people are espousing Rust for these applications, FWIW.
Rust is newer, but Go is also more relevant to the crowd here.
Most people writing web apps don't need a language where you have to worry about ownership, but they do need a language that does concurrency really well. It's the same reason you hear more about Python or Ruby than C++ here. Use cases.
Even as Rust matures, it is unlikely that people will be writing a lot of web apps in it.
Can someone explain why the parent was downvoted? Difference of opinion or is there actual reasoning. Because if there is reasoning, I'd be interested to hear it. But this seems like shaming. Stop. Or explain why he's wrong.
Other than the "Go is more relevant to the crowd here" which is a bit overarching, I don't see what's wrong here.
I'm a Python user that has my eye on Go instead of transitioning to Python3, but letting Rust/Go/Py3 all bake for a bit before doing anything (though Py3 is last on that list as I've lost faith in it at this point). I tend to agree with his viewpoint. Do go on.
I'm not sure if this is the reason, but I have noticed that there is a definite backlash against Go here and on /r/programming, especially when discussed in relation to "better" languages like Haskell and Rust.
