To quote myself elsewhere, systems programming is first and foremost cost center, not value center, programming.
That explains why it's a bit dangerous for the programmer's career.
I tend to agree, but not quite fully. To me, it's not about low-level vs. high-level or distributed programming. Systems programming tend to fall into these categories:
- Running and managing a single system: kernels, drivers, programming tools (compilers, interpreters, assemblers, libraries, linkers, loaders, etc), admin tools, package managers, graphics servers, etc.
- Connecting multiple components/systems: protocol implementations (tcp/ip, rpc, etc), message brokers, servers/daemons (database, web, cache, etc), proxies, middleware, etc.
- Virtualization: emulation, sandboxing (docker, wasm), hypervisors, etc.
Past discussions:
https://news.ycombinator.com/item?id=35092049 - March 2023
https://news.ycombinator.com/item?id=21731878 - December 2019
https://news.ycombinator.com/item?id=17948265 - September 2018
I wish bcantrill would chime in and tell us his opinion, as somebody that’s been doing actual systems programming for the last 20+ years
Programming for systems, duh.
The author completely misses the point that the term "systems programming" is an abbreviation for "operating systems programming". His entire argument seems based on this misunderstanding. Time for a re-write.
I would say that systems programming is writing software to support users of a system - those using the operating system. The same users might also be using application software - say an accounting package. Maybe the application software interacts with particular systems software, maybe not.
The implementation language doesn't matter. An example of a systems program is a distributed printer spooling program I wrote in ReXX on VM/CMS in the mid 80s. All of our VM/CMS users used it, because it was far more convenient than IBM's offering, and supported our pre-existing line printers and the physically distributed nature of our organisation.