Submitted here, to get a wider audience, and ask: does anything in Rust preclude this from being done in Rust rather than OCaml? Sounds like a nice idea...
Personally I rather that they keep on using OCaml with the C parts rewritten in Rust.
If they are successful with OCaml, it is a win for OS low level programming in GC enabled languages.
And in the process, it helps to improve the OCaml eco-system.
This without taking into consideration that the whole MirageOS architecture is based on OCaml modules, so changing language is a bit like starting from scratch.
I sometimes hack on the C part (e.g. porting Mirage to ARM). The C code in Mirage is basically:
- malloc
- printk
- openlibm (standard maths functions)
- gmp (fast big ints for crypto stuff)
- garbage collector
- support code to make the above C code compile (assert, various standard header files, etc)
Once Rust has matured, and if reliable, well-optimised replacements for all these libraries become available, then it would be interesting to use it. But until then, there isn't much C code you can replace, because there is a minimal core you need to provide to compile C libraries like gmp, and we're pretty close to that already.
Rust's linear types / lifetime support is interesting, though. For example, when you pass a buffer to Xen for transmission on the network, it's important that you don't modify it again until it has been read (or you'll get a race). Rust's type system can express that statically, whereas OCaml's can't. On the other hand, OCaml has functors, is far more mature and has lots of libraries available.
I believe several people (On both the Mirage and Rust communities) have discussed moving some or all the C code in Mirage to Rust.
If you replaced the OCaml with Rust, you wouldn't have Mirage anymore. But you could write something similar in Rust.
This video claims Mirage is pure Ocaml, so the C code may have been replaced by OCaml, but the statement still stands.
The real challenge is how much you can write in safe Rust, which is a bit of an open question. In particular, intrusive data structures are common in kernels, but tricky in Rust.
Is OCaml somehow easier for handling intrusive data structures safely? From my cursory glance, one can be pretty functional-programmey, just as in OCaml, and Rust's type system is reasonably powerful for static analysis of many things.
The OCaml module system doesn't exist in Rust, and is key to being able to fling around large abstractions with very little runtime cost.
It's worth bearing in mind that OCaml is really two distinct languages: the core ML-style language (which is concise due to type inference, and I think what the above poster is referring to by "pretty functional-programmey"), and the module language (which is verbose and signatures explicitly written down with no inference).
The latter is really the key to constructing large scale systems like Mirage, since they allow fragments of OCaml code to be mapped onto everything from Xen unikernels to JavaScript. Modules can be higher-order (that is, depend on other modules). You can read more about it at https://realworldocaml.org/v1/en/html/functors.html
It's also not yet clear how well Rust's ownership types will scale in bigger systems, but I'm sure we'll find out as the language stabilises. OCaml is a stable, fast and mature implementation of ML that has been around for years.
Nice overview of the Ocaml module system. By the way, just wanted to say thanks for maintaining the Ocaml/Opam PPA, and for keeping it so up-to-date. Has made installing and working with Ocaml much easier for those of us on Ubuntu and distros based on Ubuntu.
There are unikernel implementations in a number of other languages [1] but one of the benefits of OCaml has turned out to be the module system. I don't know much about Rust but I don't see any reason this couldn't be attempted. All the Mirage libraries are open-source [2], so taking what we've learned from these might be useful.
Submitted here, to get a wider audience, and ask: does anything in Rust preclude this from being done in Rust rather than OCaml? Sounds like a nice idea...