Unfortunately even modern C++ brings none of the benefits described in the article, because it defaults to unsafe code. Most of the Rust code from the Fuchsia team is to support Rust in applications, not in any code that needs to be trusted.
When used together with another language high level language, C++ takes the role of low level unsafe blocks. So there wouldn't exist too much difference with a pure Rust application full of unsafe blocks.
Which is the approach taken by Google on Android and ChromeOS.
My understanding is that Fuchsia would follow the same approach, using only Dart for applications.
Are there any examples of Rust applications in Fucshia?
You can't generally inline unsafe C++ into other languages (like, literally in the same file, or method) the way you can inline unsafe blocks into Rust.
This increased friction invariably leads to C++ folks making a lot more code unsafe than needs to be.
True, but tooling is much more relevant than the ability of inlining code.
It took me more time to make something usable with Gtk-rs, than it usually takes me to write JNI bindings on Android.
I used to complain about the way Google manages the NDK, quite easy to find if you search for them.
However, in the last couple of months I came to realize that it actually makes sense, it is their way to keep Android safe while keeping the door open to write some performance critical sections of code.
We were talking about the kernel. The internals of the kernel don't need to "appeal to the masses". Nor do the low-level system libraries.
You are trying to argue that C++ for system libraries plus a high-level language for apps is as secure as an all Rust app. This is empirically not true. Virtually the entire security community disagrees with you.
> So there wouldn't exist too much difference with a pure Rust application full of unsafe blocks.
There would be a massive difference, unless you're proposing they write the kernel in a high level language with little bits of C++ thrown in for the unsafe parts, which notably is not what they're already doing.
The point is to make kernel code safe by default, with a small amount of unsafe in it, all wrapped up in a safe interface for the rest of the kernel to use.
