What is "systems programming"? Roughly, writing OSes and the programs that come with the OS - compilers, linkers, debuggers, databases, and so on. The distinction is between "systems" and "application" programming. Again, this is 1960s language.
These days, there is a FAANG take on this. If I understand correctly, Google thinks of their software infrastructure as "systems programming". That kind of tracks with the old definition if you think of the entire company network as "the machine", instead of thinking about only one computer.
- functions that are called from a different language, like how parts of NumPy are written in C
- code that runs in kernel space
- code that runs on tiny little devices that don't really have an OS at all
In theory almost any language can do those things, but for a variety of reasons in practice we only use a small set of languages to do them.
Pointers cannot be escaped. They are how the computer actually works. Either you expose pointers to the user, and all the errors that can result, or you have an abstraction layer where the limited set of automatic transformations are known to be memory safe. Low level/systems languages operate at the pointer level, high level languages translate to pointers through a limited set of transformations that have been proven memory safe. Rust is a bit weird because it somehow figured out how to do manual memory management in a mostly safe way that didn't result in a huge amount of overhead. Basically Rust works like other systems programming languages that use pointers with the additional constraint that also you have to write "lifetimes" that formally prove to the compiler that your use of those pointers is safe. Think of it as writing C++ but also having to write a proof that your code is correct.
