C, still?

Always promise, never provide.

In every case, as noted in the cited article, the language offers some sort of escape hatch to do "unsafe" operations. In this detail they are equivalent to the "safe subset" promoted for C++, that a program steps out of at need.

The relevant difference between languages, for systems programming, is how effectively they can package user-defined abstractions to make it unnecessary for users to step outside the (safe) abstraction. Commonly, certain necessary abstractions can't be expressed as libraries, and so have to be built into the core language, and then are promoted as features "missing" from other languages.

In an otherwise powerful language like Haskell, for example, we see its weakness in resource management papered over with built-in garbage collection, causing the familiar integration problems. When you cannot abstract resource management, abstractions that need to manage resources other than memory necessarily leak, and in integration even memory management leaks.

The Rust project has chosen to provide expressive power, and in many cases better defaults than C++, while making it harder to accidentally do many (but not all) unsafe operations. In ten or twenty years, if it matures well, it may be a good choice for implementing a successor to Linux; but C++ isn't standing still, so the bar is rising.

There is really no way forward for the Linux kernel other than C++. At some point the choice to build as C++ or not will amount to choosing whether to keep or abandon relevance. It's not there yet. It would be better for the project to make the switch before that point.