The kernel was started before Rust 1.0, so I think that was a reasonable decision. Additionally, since it's a microkernel, the kernel is pretty small. That helps, both in the implementation now and if they ever decided to replace it. And future components can be in Rust if they want.

Bonus though, I'm pretty sure the fuschia user space has rust support already. I think their alternative to vim (xi maybe? I think it was.) is written in rust natively with python api bindings for plugin support.

Yes, xi (https://github.com/google/xi-editor) is a text editor written in Rust. It's not exactly an alternative to vim, it's more of a text editor microkernel that can have various different frontends and plugins attached which use JSON-based IPC to allow their implementation in whatever language you want. So, on macOS you can implement the frontend in Swift, and write plugins in Python or Ruby or Rust or whatever you like. On Fuchsia, the frontend is in Flutter.

It looks like while the core kernel and a lot of components are written in C++, there are a number of components written in Rust: https://fuchsia.googlesource.com/garnet/+/master/Cargo.toml

One of the advantages of a microkernel architecture is that it is relatively easy for different components to be written in different languages.

Honestly curious: why Rust specifically and not any other "secure" systems language?

Rust specifically because it has the zero-overhead safety properties via the borrow checker. This is something that no other safe language has, as far as I know. They generally either make you deal with a GC if you want safety, or deal with raw pointers and manual memory management if you want low overhead.

And the borrow checker, along with move semantics by default and the Send and Sync traits, help with several other aspects of safety as well; the Send and Sync traits encode information on what can safely be moved or shared between threads, and move semantics by default (and checked by the compiler, instead of at runtime as in C++), make it easier to encode state transitions on objects in ways that you can't try to perform operations on an invalid state.

But as others point out, Zircon, the Fuchsia kernel, was written before Rust 1.0 was released, and even after Rust 1.0 was released and stable it was still a bit rough to work with for a little while.

If you were starting a new project from scratch today, I'd seriously ask why not Rust, though of course there are other reasons why you might not choose it. But given the history, and how new Rust was at the time when this project was started, it makes a lot of sense.

>If you were starting a new project from scratch today, I'd seriously ask why not Rust, though of course there are other reasons why you might not choose it. But given the history, and how new Rust was at the time when this project was started, it makes a lot of sense.

While I'm not saying that rust is bad, Rust as a kernel language won't help you here. The simple proof is that Redox-os (which is a microkernel built in Rust) was found with the same class of bugs your average OS had.

> The simple proof is that Redox-os (which is a microkernel built in Rust) was found with the same class of bugs your average OS had.

Source? I haven't heard about these vulnerabilities.

In a kernel, there are several places where Rust won't help you. There are certain things you have to do that are going to need unsafe code, and need to be audited just as much as code written in any other language. The kernel is also a place ripe for logical vulnerabilities to creep in; it is the main arbiter of what is allowed and is not allowed from processes, so many possible vulnerabilities are logical, not memory safety issues.

On the other hand, when a kernel gets complex enough, there are places where memory safety or thread safety issues can come up even in code which doesn't require particular unsafe features and which is not involved in a security role; just things like manipulating complex data structures in multiple threads. This kind of code is the kind of code in which Rust can help catch issues; and it definitely still happens even when very good programmers, with good code review, work on the kernel.

Rust is not a panacea; it is not a cure-all. But it reduces the attack surface considerably, by containing the amount of code that is exposed to certain very common classes of bugs.

Despite the progress made over the last 24 months, I don't think Rust is ready for embedded primetime. Not to mention, the Rust learning curve is VERY steep for these guys coming from C.

Edit: to clarify ... I don't mean that they won't be able to understand the concepts ... I mean that they will lose a lot of productivity up front and won't appreciate the backend gains enough for there to be a political consensus to switch.

Also I think they started off with an existing C++ microkernel if I'm not mistaken. Wasn't it something like LM?

Rust is the "Imagine a Beowulf cluster ..." of HN.

Yeah, it's a heavily modified fork of lk.

I think the 'Better C' subset of D lang is a better match for this particular case.

https://dlang.org/spec/betterc.html

Why? The "Better C" subset of D is not memory safe, which is one of the main reasons for suggestion Rust over C++ as an implementation language. What does D offer you over Rust in this case? Better metaprogramming facilities? Is that something you really want to rely on significantly in a microkernel?