Hacker News Reader

Comment by Athas | Hacker News Reader

While I agree that Rust has advantages for performance-critical work, I don't think "systems" implies performance criticality. In the Unix tradition, "systems programming" seems to be a slightly blurry term for writing the basic tools that come with the system, not necessarily just the kernel and such. I think the term is supposed to be in contrast to "scripting", but I'm not sure the duality is that strong. For example, USENIX '91 had a paper "Awk As A Major Systems Programming Language", which implies that implementing tools such as 'nroff' (one example used in the paper) counts as "systems programming".

View on HN

In 1991 there was a very distinct job called system administrator and the really high skilled ones wrote all sorts of system administration tools in awk, Perl, Shell, and sometimes in C. This to me was 'systems programming' for the administration, deployment, automation, and management of the 'systems'.

This was in contrast to "developers" who wrote application code in numerous languages COBOL, Pascal, Fortran, BASIC, etc. And they in general, did not manage the underlying system.

Over the years I think those lines have blurred and the roles are all smashed together sometimes called devops or other terms.

Yes, this is close to what I'd also prefer to be my definition. "Systems programming" is about writing the programs that users don't care about. This involves all kinds of infrastructure: certainly the kernel, but also various other bits of critical plumbing. But that doesn't fit the definition from that Usenix paper, as nroff was an important user-visible application program, even if it isn't much anymore. I think it is probably best to avoid using the term "systems programming" except when within a constrained community where the intended meaning is clear. Just look at how much confusion arose from the original announcement that Go was a systems programming language!

I grew up with the understanding that "systems programming" is the opposite of "application programming", or, in other words, the opposite of "programs that the end user will use". So that would include the kernel, but also anything between the kernel and the end user, including compilers, servers, and so on. Yes, it's a blurry line.

BTW the term “systems programming” predates Unix. While I first encountered it through Multics I believe it’s actually an IBM or Burroughs term from the early 60s.

Hmm, interesting. I've only ever heard of systems programming referring to bare metal or close to bare metal programming. i.e. embedded software, kernel-space, or otherwise hardware adjacent programming areas.

Reply on news.ycombinator.com