Go vs C++ is not a fair comparison, because C++ is a badly designed language from the 1980s. It also serves a different domain. Certain applications of C++ are

Go vs C++ is not a fair comparison, because C++ is a badly designed language from the 1980s. It also serves a different domain. Certain applications of C++ are not serviceable by Go. Go vs Rust is not a fair comparison, because Rust's type system is much more powerful that Go's and enables applications that Go's doesn't (like embedded systems programming). Also some of the things I said about C++ apply here. There are also features of Go absent from C++ and Rust (reflection, garbage collection). So it's really puzzling that you'd pick those two. To have a fair comparison, you'd need to look at something like Kotlin sans the class system. There Kotlin is a clear winner, and with the same engineering resources put behind it, a cut-down version of Kotlin would easily be able to achieve build times in the ballpark of generic-enabled Go. Despite its claimed simplicity, Go has inconsistent design and bug-prone unwieldy features (try to write code that merges streams of data from two channels without blocking unnecessarily). It also has unnecessary constructs that contradict its claim to include only what's necessary (interfaces are just structs of function pointers, type methods are just functions with a glorified first argument). It may be enough to write one-off command line applications, but it doesn't give developers the tools to create complex distributed systems in a systematic, clean way, which was supposed to be its main area of application.