> Could you clarify what you mean by "systems programming"? To me, that means working with embedded systems, which Go is certainly not appropriate for.
The blunt but approximately correct version is that embedded means that you're running on hardware that isn't powerful enough to run a Linux kernel.
Systems programming just means you're working below the application layer. So if you take your laptop and write a device driver, or work on filesystem or networking code, you're doing systems programming without doing embedded.
No, the point of the parent poster was that "systems" is not the same as "embedded", and that while go may not work on the latter it can work on the former.
Systems does not necessarily imply embedded. I work in systems and, as far as I am aware, the term simply means software which primarily services the hardware (as opposed to the user). Drivers, HW interfaces, anything which has to make assumptions about the underlying hardware it is running on/servicing.
The blunt but approximately correct version is that embedded means that you're running on hardware that isn't powerful enough to run a Linux kernel.
Systems programming just means you're working below the application layer. So if you take your laptop and write a device driver, or work on filesystem or networking code, you're doing systems programming without doing embedded.