In the space of one week, the Go and Rust languages have both delivered new point revisions, 1.7 and 1.11, respectively. Though dissimilar, the two languages have both been trying to step up their compilation and execution.
While both matter to Go and Rust developers -- who's going to say no to increasingly compact binaries that run more swiftly? -- there are other important movements afoot in the two languages. In Go's case, it's "vendoring" to better support third-party libraries; with Rust, it's the overall stability of its libraries and ecosystem.
Under the hood...
Over the past year, Go's developers have been ginning up a new compiler back end that uses static single-assignment (SSA) to ease optimization.
"This new back end generates more compact, more efficient code that includes optimizations like bounds check elimination and common subexpression elimination," stated Go's developers in the blog post that outlined 1.7's changes.
The payoff so far has been modest but noticeable -- a 5 to 35 percent increase in speed for applications compiled for the x64 architecture. That's the only architecture supported by the SSA back end so far, but it's also the most commonly used back end, and compatibility with other architectures is in the works for future releases. The average size of a Go binary is also smaller, by as much as 30 percent.
Other changes to Go's compiler toolchain have also sped up the compilation process. This mattered more after the Go toolchain ditched its legacy C back end and compilation times went up by a factor of three. One set of third-party benchmarks put compilation times in Go 1.7 at around twice what the old C-based back end used to run -- better, to be sure, though still shy of what it could be. However, the Go linker is now faster than its C counterpart.
Rust is making similar improvements as well. Earlier versions introduced the MIR compiler back end, which generates an intermediate representation (the "IR" in MIR) of the code that's easier for the compiler to reason about.
Previous editions of the Rust toolchain included MIR as an option, but in the latest builds, MIR is the default. The resulting code not only runs a little faster, but can be more readily recompiled. That's another long-term goal for Rust that feels like a Go goal: to recompile only parts of a program that have changed, thus allowing faster development.
...and behind the scenes
One key difference between Go and Rust is their overall stability and the resulting behaviors. Go's syntax and behaviors have been highly stable, with most of the changes happening around its toolchain and the production of its binaries.
Rust, on the other hand, has been a moving target for far more of its lifetime. Its core library functionality was only stabilized as of Rust 1.6 -- released this past January -- and Rust 1.11 is still in the process of stabilizing ABIs and APIs. They're not all breaking changes, but they hint at the protean nature of Rust's language and toolchain. It isn't impossible to ship production-ready software with Rust right now, but Go has the lead, if only because Rust is the younger of the two languages.
Go is still working on improving the process for external dependencies in a particular program. Critics of Go have complained that the language's toolchain makes it difficult to deal with dependencies that have been explicitly copied into an import path. Go 1.5 added an option to handle this -- the "vendor experiment" -- and as of Go 1.7, this behavior is now enabled by default.
The next step
Where from here? For one, Rust's next big milestone may not be a particular feature of the language, although incremental compilation will make it hugely useful. Rather, the next major milestone is when a major software release ships using Rust as a significant part of its codebase. Firefox has already started shipping Rust code, but keep in mind that Rust is a Mozilla product.
With Go, don't expect the language to change much, if at all. It's the product of a small, opinionated crew of people who have their reasons for doing things their way. However, you can expect the toolset around the language -- including third-party library management -- to keep changing, as those experiences can make or break a lot of developers. And as the Go assembler and toolchain evolve, expect more experimentation in the form of entirely new languages -- such as Oden -- that depart from Go as much as they build on it.
[Edited to clarify that Rust code in Firefox is now actually shipping, not just a promised future item.]