[unscaled]

The main problem with Go is that it was originally pushed by its developers as the perfect language for these applications, and it's still actively pushed as a systems language in some circles.

The Go language FAQ still states that no "No major systems language has emerged in over a decade". Besides ignoring the system languages which did emerge, this sentence misleads the reader into thinking that Go is a systems language.

And I'm not talking about garbage collection here, which is often cited as why Go can't be a systems language. GC makes it hard to write some of the applications of a systems programming language, such as OS kernels and games, but it's not mutually exclusive, and OSes have been written in GC languages before (Lisp Machines, Singularity with Sing#). It's the entire approach: Go offers its own scheduler (which is really great, but if you need to use something else, you're in for some pain) and no support of writing dynamically linked modules. It makes go very inconvenient for most common system applications, unfortunately. Essentially, it's manages to be less high level than C++ (it has fewer robust typing and features), while not being low level enough to beat C++ in the same time (very inflexible binary target, GC-only, no inline assembly).

[Animats]

Go, the language, is better than Go, the PR. The early promotional materials claimed way too much. Some of those documents are still out there, especially "Effective Go". But the language, although overhyped, came out OK.

Go is really the successor to Java and COBOL. It's what you write your business logic in. We needed that. Java had accumulated too much excess baggage.