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.
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.
EDIT: typo, level was missing.