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.

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.

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

As does Go actually,

https://www.f-secure.com/en/consulting/foundry/usb-armory

https://labs.f-secure.com/blog/tamago/