4 ms·

Rabbitmq is a good counterexample. It is overwhelmingly used to provide services to other programs, deal with resource/performance constraints every second, but

Rabbitmq is a good counterexample. It is overwhelmingly used to provide services to other programs, deal with resource/performance constraints every second, but is an application-level program. Written in non-system programming language and not part of operating system and never will be.

mindcrime 4y ago
It's interesting in that the RabbitMQ example helps illustrate how fuzzy and subjective this all is. Some people would definitely take the approach of "it's not part of an operating system so therefore it's not 'systems' code". Personally I would disagree. I've always considered "middleware"'ish type stuff to be "systems level" by virtue of the "it mainly provides services to other software" aspect of the definition seen above. Web browsers are another interesting item that don't fit neatly into this classification either. I mean clearly a browser is something that provides services directly to the user. You use it to navigate the web, view and download documents, store bookmarks, and all sorts of stuff. It's 100% "application level." Except... the browser also provides a runtime, including memory and process management, networking services, graphical rendering, etc. to other software. In fact, a browser is basically a poor man's Operating System. So it's 100% "systems level." Wait, what?!??
- jasode 4y ago
  >I've always considered "middleware"'ish type stuff to be "systems level" by virtue of the "it mainly provides services to other software" aspect of the definition seen above. The middleware-programming is also systems-programming was also reinforced by Rob Pike when he originally presented Go as a "systems language". However, he now admits[1] it confused people and Go might be better categorized as a "server" apps language -- i.e. writing Google's backend infrastructure code that doesn't need to be written in C++. In the 1980s, "systems programming" was usually a synonym for "bare metal programming" because "systems programming" was just a shorter way of saying "_operating_ systems programming". (One writes an operating system to boot up on bare metal.) And systems programming was typically assembly/C/C++ instead of business programming like COBOL or dBASE. In that mode, writing kernel drivers or a UEFI boot loader is also "systems programming". In contrast, "applications programming" was something else. That said, if today you surveyed 100 random programmers in various domains, I'd have no idea if there's a dominant view of what systems programming is. [1] from the article: Rob Pike: When we first announced Go, we called it a systems programming language, and I slightly regret that because a lot of people assumed it was an operating systems writing language. What we should have called it is a server writing language, which is what we really thought of it as. Now I understand that what we have is a cloud infrastructure language. Another definition of systems programming is the stuff that runs in the cloud.
pjmlp 4y ago
Which is quite interesting when we then talk about microkernels and hypervisor based workloads.
deleted 4y ago
[deleted]
sillybov3456 4y ago
I think based on the parent posts choice to go with the "who is your customer" definition and the fact that we intuitively think of RabbitMQ as some sort of systems program, it probably fits the modern definition of systems program that we all kind of agree with but do not necessarily put into words. I don't think RabbitMQ being written in a "non systems language" is relevant. Its a systems program even if it was written in shell (if it was it might be a bad systems program, but a systems program nonetheless because of it's intended customers and use case). Which brings us to browsers, which are not systems programs (and I think we tend to not think of them as such) almost entirely due to their primary customers not being programmers. This is despite the fact that they fit the "complexity/size and close to the metal" definitions a lot better than many other programs that are commonly considered to be systems level.

mindcrime 4y ago

It's interesting in that the RabbitMQ example helps illustrate how fuzzy and subjective this all is. Some people would definitely take the approach of "it's not part of an operating system so therefore it's not 'systems' code". Personally I would disagree. I've always considered "middleware"'ish type stuff to be "systems level" by virtue of the "it mainly provides services to other software" aspect of the definition seen above. Web browsers are another interesting item that don't fit neatly into this classification either. I mean clearly a browser is something that provides services directly to the user. You use it to navigate the web, view and download documents, store bookmarks, and all sorts of stuff. It's 100% "application level." Except... the browser also provides a runtime, including memory and process management, networking services, graphical rendering, etc. to other software. In fact, a browser is basically a poor man's Operating System. So it's 100% "systems level." Wait, what?!??

jasode 4y ago
>I've always considered "middleware"'ish type stuff to be "systems level" by virtue of the "it mainly provides services to other software" aspect of the definition seen above. The middleware-programming is also systems-programming was also reinforced by Rob Pike when he originally presented Go as a "systems language". However, he now admits[1] it confused people and Go might be better categorized as a "server" apps language -- i.e. writing Google's backend infrastructure code that doesn't need to be written in C++. In the 1980s, "systems programming" was usually a synonym for "bare metal programming" because "systems programming" was just a shorter way of saying "_operating_ systems programming". (One writes an operating system to boot up on bare metal.) And systems programming was typically assembly/C/C++ instead of business programming like COBOL or dBASE. In that mode, writing kernel drivers or a UEFI boot loader is also "systems programming". In contrast, "applications programming" was something else. That said, if today you surveyed 100 random programmers in various domains, I'd have no idea if there's a dominant view of what systems programming is. [1] from the article: Rob Pike: When we first announced Go, we called it a systems programming language, and I slightly regret that because a lot of people assumed it was an operating systems writing language. What we should have called it is a server writing language, which is what we really thought of it as. Now I understand that what we have is a cloud infrastructure language. Another definition of systems programming is the stuff that runs in the cloud.

pjmlp 4y ago

Which is quite interesting when we then talk about microkernels and hypervisor based workloads.

deleted 4y ago

[deleted]

sillybov3456 4y ago

I think based on the parent posts choice to go with the "who is your customer" definition and the fact that we intuitively think of RabbitMQ as some sort of systems program, it probably fits the modern definition of systems program that we all kind of agree with but do not necessarily put into words. I don't think RabbitMQ being written in a "non systems language" is relevant. Its a systems program even if it was written in shell (if it was it might be a bad systems program, but a systems program nonetheless because of it's intended customers and use case). Which brings us to browsers, which are not systems programs (and I think we tend to not think of them as such) almost entirely due to their primary customers not being programmers. This is despite the fact that they fit the "complexity/size and close to the metal" definitions a lot better than many other programs that are commonly considered to be systems level.