Nothing makes programmers more excited -- or more opinionated -- than a new language to sink their teeth into. Currently, programmers can feast on two rising stars: Go and Rust, each with similar inspirations but radically different motives and targets.
Both languages have top-notch pedigrees, created under the auspices of major forces in modern IT. Go was hatched at Google by (among others) Rob Pike and Ken Thompson; Rust was Graydon Hoare's brainchild at Mozilla Research. Both began as experimental projects, but quickly flowered into full-blown development efforts.
From there, the two languages diverge sharply. They weren't created for the same kinds of work or the same audiences, despite both leveraging the legacy of C and C++. Here are a few big points to consider when determining which language is best for what kind of application.
What is the language for
It's always tricky to say what a given programming language is best for, given the open-ended nature of most languages, but it is still possible to narrow the playing field. Go was devised in the tradition of and is meant to be picked up quickly by those familiar with C; however, it isn't intended for system programming. Rather, its feature set (goroutines, channels, and a variety of concurrency patterns) are a better fit with distributed applications such as Etcd, the distributed key-value system used by CoreOS to synchronize settings between nodes.
Rust, on the other hand, is closer to C in terms of the kinds of programming it can handle. Focused on "type safety, memory safety, concurrency, and performance," Rust is intended for reliable system-level programming as much as for distributed client/server applications. In short, Rust can address many of the same programming tasks as Go, but Go can't do so for Rust.
Easy or safe? You choose
Because of Go's roots in C, the number of features in the language remains relatively small. Type inheritance, generics, and method/operator overloading are all deliberately left out, though some have been indirectly re-created elsewhere -- for instance, having interfaces instead of inheritance. Garbage collection and memory management are built in, mostly for programming ease.
Rust, by contrast, is constructed for safety first, due to the interoperation between the language design and compiler behavior. Variable types don't have to be specified, but the compiler provides detailed feedback about their use, so it's very difficult to run code that might be unsafe. That said, the language also provides ways to tag operations as unsafe, such as inline assembly code.
The leader of the pack
Go has the biggest lead in the simple fact that it's been in production use for some time -- not for obscurities, but for today's bigger-name software projects. Docker comes to mind, of course, but there are others: the Etcd project from CoreOS, the Deis PaaS, InfluxDB, and many more. The language also features a robust standard library and numerous community-created packages.
Rust, as the newer kid on the block, has very little code used in production, in large part because of its sheer newness. Also, Rust was highly protean during its development, so little production code was built around it. Now that the language has stabilized, we'll likely see more real-world Rust projects developing.
Where does each go from here? Go's last major release was in December 2014, and the next major version is scheduled for six months out. Changes slated for 1.5 include writing all of Go's toolchain in Go itself and a major overhaul to garbage collection.
With Rust, a full 1.0 release is scheduled for sometime after Feb. 16, which is when the beta of 1.0 is expected. Following that, we might see dramatic progress on one of the more whispered-about projects in the works: Servo, an HTML rendering engine written in Rust to take advantage of the parallelism inherent in modern hardware.