Xen is a hypervisor that provides secure isolation, resource control, quality of service guarantees, and virtual machine migration.
The XCP-ng platform developers, which is developed under the wing of the Xen project, have released a plan to create a Rust replacement for various components of the software stack Xen.
The Xen hypervisor itself is yet to be processed and work is mainly focused on reworking individual components of the toolset.
The platform currently uses components in C, Python, OCaml and Go, some of which are outdated and cause maintenance issues. It is observed that using Rust will not lead to an overall increase in the number of languages involved, since only one component is implemented in Go, which is planned to be replaced in the first place.
Obviously don't expect us to rewrite the Xen hypervisor and everything in Rust as our first attempt. In fact, our goal here is to start replacing some of the smaller components around it, allowing us to "grow" the language itself and think about how to replace things block by block, for the entire platform.
Rust is chosen as a language that combines high code performance Resulting with safe memory capabilities, does not require the use of a garbage collector, is suitable for developing low-level and high-level components, provides additional features to reduce potential errors, such as the variable borrower (borrow checker). Rust is also more widespread than the current XAPI language OCaml, which will make it easier to attract new developers to the project.
In the first stage, it is planned to develop replacements for various components cin order to resolve the processes and prepare the base to replace other parts of the software stack. In particular, firstly, the Linux guest tools will be rewritten in Rust, for which the Go language is currently used, and the background process for collecting metrics will be written in OCaml.
Since Rust is safe and fast, what else do we need? We also need a programming language that is capable of working at various levels (bottom and top of the stack). I wouldn't trust Go or Python to deal with such low level things that we can have in XCP-ng, and similarly not C to do higher level things. The use of Rust provides the potential to be everywhere in the XCP-ng stack'.
Also, Rust is no longer a "niche" language. For example, even if it's great, OCaml (used in XAPI) isn't well known, which reduces our chances of easily hiring people with experience in this language. This also reduces the ability of an open source community to gain contributors. We think Rust won't be a hindrance to that (both hiring and contributions), probably even the opposite: a driver to attract more people, as it's a "wanted" technology.
The need to redesign the tools of linux guest tools (xe-guest-utilities) is due to development and code quality issues outside of the Xen Project under the control of Cloud Software Group, which makes packaging and community influence on development difficult. It is planned to create a new variant of the toolset ( xen-guest-agent ) completely from scratch, keeping it as simple as possible and separating the agent logic from the libraries. We decided to rework the back-end process for collecting metrics ( rrdd ), since it is compact and separate, making it easy to experiment with using a new language during development.
Next year, work will probably start on the development of the xenopsd-ng component in Rust, which will allow us to optimize the architecture of the software stack. The main idea is to concentrate the work with a low-level API in one component and organize the provision of all high-level APIs to the rest of the stack through it.
Finally, if you are interested in knowing more about it, you can consult the details In the following link.