[jkn]

Indeed. But looking at the GC improvements in Go 1.8 ("typical" GC pauses of less than 100us), the set of cases where you can't use the language might be shrinking significantly. Now if only they could turn that in some sort of guarantee...

[pcwalton]

The sole performance metric of GC is not pause times! Throughput matters just as much if not more!

GC pauses are not the only reason to use Rust. Rust is not "little Go" that you reach for only if you don't want GC. You might want package management, data-race-free concurrency, a mature optimization framework, runtime-free operation, concurrent data structures, fast C interfacing, etc. etc.

[jkn]

You're right of course about the GC metrics. And there was some disappointing increase of GC CPU usage with the 1.8 changes (I don't now the current status). But some of the items you mention (package management, mature optimization framework) will hardly make cases where Go cannot be used, which was the original point. Same for concurrent data structures which can be implemented in Go, even if the lack of generics makes it less convenient. I do agree with you regarding the other items.

[pcwalton]

Aggressive compiler optimizations are not optional in many domains.

One rule of thumb that a lot of people don't realize is that if you aren't maxing out your sequential performance, your parallel multicore algorithm usually loses to an optimized sequential one. The reason is simple: parallelism introduces overhead, leading to guaranteed sublinear speedups. Compiler optimizations, on the other hand, frequently result in multiple factors of improvement.