They are smart guys, so I can only conclude that "systems programming" means something different to them than it does to many other systems programmers.

To me, "no imposed GC" is a non-negotiable element of being a systems programming language. So I am far more drawn to Rust than Go.

"Systems" in Rob/Ken's time was services/servers - what we call applications these days.

And of course, them being Go's authors and them being wrong on characterizing it, is in no way contradictory.

« No major systems language has emerged in over a decade, but over that time the computing landscape has changed tremendously.

(...)

We believe it's worth trying again with a new language, a concurrent, garbage-collected language with fast compilation. Regarding the points above [cut on edit]:

* It is possible to compile a large Go program in a few seconds on a single computer.

* Go provides a model for software construction that makes dependency analysis easy and avoids much of the overhead of C-style include files and libraries.

* Go's type system has no hierarchy, so no time is spent defining the relationships between types. Also, although Go has static types the language attempts to make types feel lighter weight than in typical OO languages.

* Go is fully garbage-collected and provides fundamental support for concurrent execution and communication.

* By its design, Go proposes an approach for the construction of system software on multicore machines. »

It is still at the forefront of the language presentation.