I've recently started learning Rust. If you haven't heard of it before, it is a new programming language which initially spawned out of Mozilla.
Rust is interesting in that it is a language with a lot of modern concepts baked in from the start. I'm interesting in learning more about its memory management semantics and other aspects of the language like pattern matching and error handling patterns. Rust could, hypothetically, be used to build an operating system and some folks are experimenting with this already.
Often Rust is pitched as a great "system programming" language - but what does that really mean? When most people think system programming they think operating system code, device drivers, utilities, compilers and other fundamental software components.
Today a lot of really low level operating system code is written in a combination of various platform specific assembler languages and C code written with absence of the C libraries which depend on the operating system itself. Once you get out of the operating system kernel and away from writing device drivers your options for languages and runtimes open up dramatically.
For example, if you wanted to build a tool that needed to run on Linux, Windows and macOS - on a variety of CPU architectures - then you could pick up .NET Core, it's already quite portable. Yet people will tend to eschew something like .NET Core on Linux for system programming tasks because of the dependency graph. But many useful non-kernel/driver system tools end up needing these libraries anyway. If something like .NET Core is portable enough between platforms and CPU architectures then why not benefit from the language and runtime features?
Linus Torvalds has a famous rant on why C++ is not used in the Linux kernel which is always an amusing read. I don't write operating systems so I'm not qualified to comment. But outside of operating systems, I think that higher level languages with "small enough" dependency graphs are just fine for system programming tasks.