For the more traditional definitions of "systems programming", yes. I would agree with that.
However I don't think anybody is really marketing Go for that niche.
However I don't think anybody is really marketing Go for that niche.
Today, "systems programming" is more taken to mean "kernel programming", and I don't get the sense that is what was meant by the senior authors of go.
Choose the greatest impediment and cite it as a primary goal.
http://en.wikipedia.org/wiki/System_programming
Last time I looked, inside of the Go libraries which had to do some tricky things there was some C code, meaning that even Go authors weren't able to write everything in Go. So Go can't be a substitute for C, and as long as most of the system programming is done in C, no go for Go.
Parts of the runtime are written in C and assembly, but that's because there is power in breaking abstractions: http://research.swtch.com/goabstract
As it stands today, Go can be used to write operating systems. Yes, you will have assembly, yes you will likely also have C, so what?
I suspect that it isn't so much that they aren't able to write everything in Go, but more that it isn't a priority for now. It wouldn't surprise me if Go wasn't eventually self-hosting.
It is already well equipped to write distributed network servers, web servers, message queue servers and such.
Anyway, "systems" in this case includes daemons and server processes. I'll update with a reference if I can find it in the Go context.
For that sense of "systems", Go excels and Java enjoys a great deal of popularity.