For me "systems programming" is just low level programming

Systems programming is when you break-out from your shiny MVC API and libraries, and start reading section 2 of the Linux/BSD manual. When you start caring about process and thread affinity, memory allocation patterns, CPU cache performance, etc.

Yet an operating system is at a higher level, above the kernel. Traditionally, systems have been the middle ground between the low level and the high level. But ultimately words only mean what ever you define them as in the moment, so system can mean anything you want it to, so long as that meaning is conveyed to others needing to understand how you are using the word.

The problem with that distinction is that the word “system” doesn’t get to have a say in any of it. A system is something that is put together from smaller, distinct components in such a way that it has emergent properties not inherent in its components. Is systems programming to provide such components so they can be put together by application programmers? If yes, then “lower level” is entirely relative. A component might be a hardware driver, a service in the cloud or a set of primitives in your game engine. This would also mean that the term is recursive. Anyone who is programming components or larger parts of a system that can be put together is now systems programming. So the web developer who handles content negotiation for both end user consumption (html) and further processing (json) is now systems programming? It’s all a bit confusing with this term.

Which can even be done in BASIC, like on the 8 bit home computers, or the BASIC compilers available for MS-DOS, VAX/VMS, HP-UX and so forth. Xerox PARC systems programming was done in Smalltalk, Interlisp-D, Mesa/Cedar, where garbage collection was part of the picture. Likewise at ETHZ with the various kind of Oberon based systems they produced. I was lucky to have done systems level stuff in BASIC, and Pascal before getting to learn C and C++, as I wasn't subject to the misunderstanding C and C++ are the only way to do systems work. What matters is understanding how the hardware works, and actually how that high level stuff maps into Assembly.

There's a slight variation on this, although I never saw it said out loud: Low level or not, system programming is about interacting parts. Long ago, low level meant sending messages/signals to various chips to have the desired effect. It was cryptic and full of time and space constraints, and people equate system with these complex topics but to me the "interacting parts of a system" is still an important aspect of the definition. That's why I accepted go being a system language, it just wasn't operating at the electronic layer, but the computer/node level.. but it was meant to orchestrate messages concurrently between all these nodes, just like chips and signals long ago.