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.
