I'm with you. IMHO, Go's simplicity is its biggest virtue. It has fostered a community that values consistency and clarity over syntactic sugar. And, as a result, I find each new codebase extremely accessible.
Normally it's the other way around, Go gets compared to other "Systems Programming" languages because somehow services got lumped in with that name over the last few years.
To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language.
Go gets compared to "systems programming" languages because its designers specifically intended it to be used as such [1][2], albeit the definition of 'systems' they are using is deliberately evolved from the original shade of meaning as suggested by low-level languages that are sometimes deemed to be for 'systems programming' to illustrate that the nature of environments has changed, and a new approach is advantageous.
It gets compared with them because that is what it is particularly good for. Arguably, it is much less suited to Type 1 representational systems (http://aryehoffman.com/entry/project-types), for the same reasons as for the C language. Like C, it is particularly suited to Type 2a projects - those in computing and its infrastructure.
Rust, too, had an optional GC (where the choice is per-data, not global) for a long time and still intended to be a systems language (And was pretty successful at being systemsy IMO). I think there was a time when &-pointers didn't exist and all sharing was done through the GC too. At one point there was a realization that the new borrowing system could be used to write GC-less programs pretty easily, and that was a turning point after which the GC started being phased out in community usage and eventually removed from the language.
I never said anything about having a GC, just that if you can't poke directly at memory when you need to then you're going to have a heck of a time working on the Systems Programming space.
Also remember Go was inspired a lot by Oberon-2. The Oberon languages were used for writing operating systems despite a GC. They just used assembly or UNSAFE constructs for stuff the type-safe or GC parts couldn't handle.
I think you have this backwards. 'Systems programming' has never meant 'operating systems'. To believe that Go is misdescribed as a 'systems programming' language you have to believe Rob Pike doesn't know what 'systems programming' means.
Given Pike's extensive experience inside a world of his own making (Plan 9 and Go), it's entirely reasonable to attribute the misconception that Go is a system language to Pike's idiosyncratic use of the phrase.
If I understand things correctly, Go came about as fallout related to the non-scalability of Python and the massive technical debt associated with Python within Google. The projects to automagically port Python code to Go code are a clear indicator that Go was at least in part imagined as a replacement for Python.
I personally wouldn't describe Python as a systems language, but some might.
There's nothing idiosyncratic about it. "Systems Programming" has meant a lot more than just "operating systems" for at least as long as I've been doing this stuff, which dates back into the 90's. Maybe in some earlier age it was the case that "Systems Programming" was limited to "operating systems" but if so, it was quite some time ago. Language evolves...
Yeah, one of the cool things about go is it's ability to get reasonable compile times without byzantine management of include files, as in c++. I still don't know of any major c++ code base being targeted by go, whereas python is certainly in the crosshairs.
The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software which provides services to the user directly (e.g. word processor), whereas systems programming aims to produce software and software platforms which provide services to other software, are performance constrained, or bothhttps://en.wikipedia.org/wiki/System_programming
By that definition it seems pretty clear that systems programming covers a lot more than just operating systems. But calling a language a systems programming language if it is unsuitable for writing operating systems seems a bit unusual. At least it would have been unusual at the time these terms were originally coined.
Why would I? They support what I said directly - 'system programming' is not limited to operating systems. Here's a bit from one of the Wikipedia entries you mention.
"System software is computer software designed to operate and control the computer hardware, and to provide a platform for running application software. System software is computer software designed to operate and control the computer hardware, and to provide a platform for running application software. System software includes software categories such as operating systems, utility software, device drivers, compilers, and linkers."
"System software includes software categories such as operating systems, utility software, device drivers, compilers, and linkers"
Most of those things can be summed up as "operating systems" (operating system, device drivers, and utility software, e.g. basic backend services) plus some essential supporting stuff (compiler and linker).
So, yeah, it's pretty much constrained to "operating systems" and the few essential items. It's not about network servers the kind Go is used for.
And further, in my view, if manual memory management is extraordinarily difficult a language is not necessarily a good candidate for systems programming.
You can relatively easily get to manual memory management using Go's runtime, i.e. access those runtime·sysAlloc(), runtime·sysFree() functions directly, the way Go accesses syscalls in the external sys package [1]. It's like ten lines of code, nothing extraordinarily difficult.
The difficulty of manually managing memory isn't necessarily to do with how many lines of code it takes to allocate or deallocate. The difficulty is in managing the scope of the rest of the program that is now susceptible to memory errors, which extends far beyond those initial ten lines of code if encapsulation is done inexpertly.
People comparing it to C++ and Rust miss the point.