If your domain of discourse is the computer itself or the functionality of the computer in the world (store/compute/ communicate) than it is system programming. Else it is application programming.<p>It has nothing to do with the actual programming language.
I think it would be a unfortunate for people to start redefining what "Systems Programming" means because it is vague enough now as it is - and we don't have the luxury of being able to go back and update the term in the historic literature.<p>My understanding is that, in effect, "Systems Programming" is analogous to "Operating Systems Programming", or rather you might say (given the increasing size of operating systems these days) that "Systems Programming" is a subset of "Operating Systems Programming" that deals with the direct manipulation of memory in order to provide a useful abstraction for "user" software - remembering that most hardware interaction is via memory. Obviously, in order to do "Systems Programming" you need a "Systems Programming Language" that allows such direct access to memory.<p>These days, "Systems Programmers" would be those working on the Linux kernel, or microkernels, or graphics drivers (basically those who have complete access to memory) though those developing services one layer up might also consider themselves to be such (especially micro-kernal-based operating systems).<p>It is probably worth emphasising that "System" is a generic term that is used in a lot of different contexts. I think "Systems Programming" is used in the context of a "Computer System", while modern day cloud programming would be better described as "Distributed Systems Programming" as it is in the context of a "Distributed System" (though I've probably just annoyed a whole bunch of distributed systems researchers).<p>I think that what the author of the article is talking about is "System Architecture" (or perhaps "Distributed Systems Architecture").<p>Should we talk about this as programming at all?
I've primarily writing C++ for over 15 years. I don't think I'd ever heard the term "systems programming" until the last few years when Rust talked about it. I don't have a super formal CS education and most of my career has been in gamedev.<p>What is sytems programming? I don't know. I don't care either. It's an arbitrary label that is rarely used and doesn't affect anyone in any way.
> To summarize, what we call “systems programming” I think should be called “low-level programming.” Computer systems design as a field is too important not to have its own name. Clearly separating these two ideas provides a greater conceptual clarity on the space of programming language design, and it also opens the door to sharing insights across the two spaces: how can we design the system around the machine, and vice versa?<p>Alternate definition whose source I can't recall:<p>Systems programming is everything that isn't application programming.<p>Maybe it's time to update that with:<p>Systems programming is everything that isn't application programming or low-level programming.
Maybe not the thread to post this, but I've seen too often "systems programming" be intertwined with arrogance and gatekeeping. As if these skills are special and inherently more difficult to pick up by developers without them. But tbh all software engineers are programming abstract machines at various levels. Systems work is just a different abstract machine to grok.<p>My education is in relevant skills (CompE), but the attitude I keep running into in this domain has really started to disgust me, even if it isn't everyone. When it's people I've seen in leadership, that's enough :/
Systems programming concerns the code between hardware and the application programmer. So pretty much kernel programming.<p>Application programming concerns the code between kernel and the ordinary user.<p>Essentially, systems programmers write software that application programmers can interface with. Application programmers write software that ordinary users interface with.<p>It gets fuzzy at the edges like most definitions, but that's how I think about it generally.
One litmus test that a former coworker applied was "how resource constrained is the application"?<p>I think conceptually this is a better test, more so than say if you have access to a raw pointer - because more important parts of how to handle core issues like scheduling, storage management, concurrency, parallelism and distributed computation manifest themselves in many forms.<p>I started my career doing C programming in a OS / kernel environment. In retrospect a lot of pieces of applications I've worked on are what I think of as systems, and many parts of kernels are more applications than systems.
Discussed at the time: <a href="https://news.ycombinator.com/item?id=17948265" rel="nofollow">https://news.ycombinator.com/item?id=17948265</a>
I was really liking this article, until the "dynamic typing sucks" and "functional programming is the path to enlightenment" stuff came up at the end.<p>Specially jarring because it's out of nowhere. That conclusion does not follow from everything that comes before.