[jtakkala]

I think it was Rob Pike who later said he regretted using the term "systems programming" to describe Go. They never meant the phrase to mean purely operating system tools and programs (ie. not web applications or interactive end-user applications), which would be rather limiting. Instead, he said he said they meant it as a language for composing systems, as for example a typical SOA web site may be, or even for application development as you've alluded to.

Edit: Rob mentions it here at 06:50: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pan...

[pjmlp]

Real systems programming would be possible with a little more help.

Meaning a few more operations exposed in unsafe.

The problem is that the average developers never saw Oberon line of languages or are unaware how much of libc is actually written in Assembly.

Maybe with Go 1.5 fully re-written in Go, it will be easier to sell this scenario.

[orbifold]

According to Github 8.4% of glibc is written in assembly. You would actually expect that to be an over estimate, since assembly is guaranteed to be machine dependent.

[ahh]

I suspect this is a significant underestimate: glibc heavily relies on generated assembly (they have a set of scripts to generate boilerplate asm functions for system calls) and inline assembly (which gets defined once, probably counted as C by github, and used many times.)

[Dewie]

With that in mind, I tried to use the phrase in a more wide sense than some other language communities would. But you're right that that phrase might as well be disassociated with the language at this point, to avoid confusion. Better to find a new word for it.