4 ms·

> This exposed Rob Pike's lack of experience in the area (IMHO) because anyone who had done any systems programming at all knew that garbage collection made any

> This exposed Rob Pike's lack of experience in the area (IMHO) because anyone who had done any systems programming at all knew that garbage collection made any systems language a nonstarter. What exactly do you mean by systems programming? Many successful databases (Cassandra, Kafka, ElasticSearch) are built on the JVM.

cletus 6y ago
I guess "systems programming" is an ambiguous term here like I personally wouldn't call something "systems programming" just because it's server-side. What I mean is things that are basically kernel-level or embedded.
- pjmlp 6y ago
  So given embedded soft real time bare metal Java AOT compilers, Java gets to be a systems language as well. :) https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc As does Go actually, https://www.f-secure.com/en/consulting/foundry/usb-armory https://www.f-secure.com/en/consulting/foundry/usb-armory https://labs.f-secure.com/blog/tamago/ https://labs.f-secure.com/blog/tamago/
rsj_hn 6y ago
Many people consider "systems programming" to be close to the hardware stuff that is not visible by users. Userland code would generally not fall into this category, with the weird proviso that some OSs put a lot of GUI code into the kernel (cough windows cough). In this traditional classification, a database is considered an "app". The "find" command is an app. People log in and use the DB and the find command. The Bash shell would be an app. If a user is using it, it's an app. If it is not user visible but exists to manage app access to hardware resources, it's a system. So a memory management system would not be an app. Neither would power management or IO or a scheduler. But these systems might have administrative apps that admins login and use (like Microsoft's "Control Panel" app -- to control settings for the system code. Similarly some apps might have their own memory management system. But the principle still applies. I understand there is definition creep as more and more layers sit between the user and the hardware, so todays application code might, in some cases, be viewed as tomorrow's system code, but this is the original meaning.

cletus 6y ago

I guess "systems programming" is an ambiguous term here like I personally wouldn't call something "systems programming" just because it's server-side. What I mean is things that are basically kernel-level or embedded.

pjmlp 6y ago
So given embedded soft real time bare metal Java AOT compilers, Java gets to be a systems language as well. :) https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc As does Go actually, https://www.f-secure.com/en/consulting/foundry/usb-armory https://www.f-secure.com/en/consulting/foundry/usb-armory https://labs.f-secure.com/blog/tamago/ https://labs.f-secure.com/blog/tamago/

rsj_hn 6y ago

Many people consider "systems programming" to be close to the hardware stuff that is not visible by users. Userland code would generally not fall into this category, with the weird proviso that some OSs put a lot of GUI code into the kernel (cough windows cough). In this traditional classification, a database is considered an "app". The "find" command is an app. People log in and use the DB and the find command. The Bash shell would be an app. If a user is using it, it's an app. If it is not user visible but exists to manage app access to hardware resources, it's a system. So a memory management system would not be an app. Neither would power management or IO or a scheduler. But these systems might have administrative apps that admins login and use (like Microsoft's "Control Panel" app -- to control settings for the system code. Similarly some apps might have their own memory management system. But the principle still applies. I understand there is definition creep as more and more layers sit between the user and the hardware, so todays application code might, in some cases, be viewed as tomorrow's system code, but this is the original meaning.