The people who designed golang did not have PhDs in PL. They were not even PL designers to begin with, and it shows at how poorly designed it is. (And no, one person who happened to work on C doesn't count, since language design evolved a lot since then).

Incidentally, golang did not end up replacing C++ or Java in the slightest, especially at Google. It is in the same space as python.

I have criticisms of Go too, but your statement is factually incorrect. Robert Griesemer did a PhD under Niklaus Wirth.

Thanks for the information, I didn't know that. It just make it weirder how the language turned out. Perhaps he didn't influence the initial design enough?

Having a PhD on a field does not automatically imply you can produce good results, specially if targeted for widespread consumption. It is actually very rare when that happens.

I am not saying that is the case here one way or the other, though.

Under Niklaus Wirth nonetheless, that's just awesome, the grand dad of performant compilers.

Having a PhD means you studied for years to push boundaries, nothing more, nothing less. Lets not forget that the bosses usually decides exactly what should be done with sprints and standup, especially in teams that are not research focused.

Actually I think go is semantically much closer to oberon than to C.

Or for systems coding and performance-critical work, Rust.

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".

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.