XCP-ng Initating Effort To Rewrite Xen Components In Rust

[Quackdoc]

I would sum up Xen this way: it's a different but very interesting design (vs KVM). However, like KVM, there's little chances you might use Xen "alone" if you want to scale a bit. What matters in this case is the toolstack around. In a way, XCP-ng is closer to VMware (regarding the design). That's not a coincidence that almost all our new comers are from VMware

I am not the most familiar with vmware, but have used it a bit, though since most of my use cases require emulated 3d (IE. virgl/venus) in linux, qemu via libvirt is what im most familiar with, but lately i've been doing stuff where that isn't so necessary.

for xcp-ng/xen is there any discussion around potentially using crates from rust-vmm should testing the rust migration waters and the conclusion is that it seems viable? I can see both pros and cons, it seems like it could reduce longterm maintenance a bit, on the trade off of needing to spin off upstream should the two paths not align. at the very least the general direction of rust-vmm, being safe and reliable. at the very least, IIRC both crosvm and firecracker use bits of it.

can't wait to check out xcp-ng though, will certainly be looking into it soon

[patrick1946]

Go is not fully memory safe, but I haven't actually seen that being an issue in practice (unlike the shitshow that are C and C++).

Actually it would be nice if people don't think that C and C++ are the same language. C++ is quite compatible with C but that's it. You can handle resources in C++ quite well but you are not forced to. Many still write a quite outdated C++. That is the drawback of compatibility.

And the compiler is not ensuring that your resource management is right to the extent that Rust doing it. You have to use tests and reviews. For many applications it is okay because they are not security sensitive. You have to write tests anyway because many errors are not detectable are compile time.

But people don't do write tests or the quality of the tests are bad. That is not a C++ only problem but especially C++ because many programmers are older and don't want to change.

I really would like if there is pressure to a more modern, safer C++ subset. With modules they could introduce epochs. I think it is not economical to rewrite all the C++ code in different language.

[OneTimeShot]

Wow - this project has lasted much longer than I thought it would have. This stuff does the remote configuration of a XenServer computer cluster (create VMs, set up networks, file storage, etc). It does what libvirt does basically.

I'd be interested if there is any functionality that libvirt is missing that this has (I doubt it).

[jacob]

You probably don't want to write the hypervisor in Go or OCaml because of the garbage collection, that's right. But for userspace tools, it should be fine (both have a pretty low GC latency). Go is not fully memory safe, but I haven't actually seen that being an issue in practice (unlike the shitshow that are C and C++). I don't know how mature the paralaelism is in OCaml now, since I have started writing my own code in Rust before multicore was merged.

I agree that for userland tools they are great languages, Go in particular has become quite popular in the Linux container management ecosystem. Canonical's Snap package manager is also written in it IIRC.

I haven't looked at OCaml literally in more than 20 years so I'm not sure where it's at now in terms of parallelism. I think back then the GC was not thread safe and thus OCaml only supported concurrency/"green threading" but not actual parallel execution. But I could be wrong about this.

[archkde]

They are fine languages, but neither can match the performance of Rust. Both are also garbage collected, which makes them unsuitable for certain application areas. Go also doesn't provide the same safety guarantees.

You probably don't want to write the hypervisor in Go or OCaml because of the garbage collection, that's right. But for userspace tools, it should be fine (both have a pretty low GC latency). Go is not fully memory safe, but I haven't actually seen that being an issue in practice (unlike the shitshow that are C and C++). I don't know how mature the paralaelism is in OCaml now, since I have started writing my own code in Rust before multicore was merged.

[andrei_me]

One thing that I like about Rust is that it allows devs with background in other languages besides C/C++ tap into the same level of perf without needing to learn/handle/deal with C/C++ baggage.

There's several blog posts on how python/javascript devs can use rust in performance critical ccod

I haven't used C before nor follow it's development closely, but I know about C89, C99 and later versions, you have GNU extensions, the newer auto keyword and so on.

Sure the borrow checker can be a PITA, but it is like a English speaker learning a Latin based language, you need to think about things that doesn't exists in English

[smitty3268]

...

I think you are correct that Rust is more designed as a successor to C, and not C++. Whether that's good or bad may depend on your personal preferences. In many cases I think something more like Go or C# may be better suited as a C++ successor, or just using future versions of it as it evolves.

[darkonix]

I am not so sure. Rust is a difficult language by design. For many things Python should be easier.

Depends, as always. Build scripts helpers, and test scripts are usually best left in python. Whatever they are doing in the application maybe be better ported. They didn't mention actually porting the python code for now.

[patrick1946]

Rust has a reputation of being difficult but honestly it's not nearly as bad as it's made out to be. Of course if you coming from either a Java/C# background, or a C or C++ background and you expect Rust to be pretty much the same with a different syntax and some conveniences here and there, then you will hit a seemingly insurmountable mountain of roablocks. But if you don't try to do C in Rust and instead deliberately try to use Rust idiomatically, keeping in mind that references, scopes and lifetimes mean something very different than in C and C++, and if you buy into the whole approach heavily slanted towards functional programming, then it's really not that hard to get you code past the maniac compiler.

Yes, that I mean by difficult. I really wanted to like Rust but I find Rust quite metaphysical approach not seducing. It is not very pragmatic. I got the impression that it was written by people who dislike C++ and want to develop a better C. I understand that there are bad ideas in C++ but in my view templates are not. They are a very powerful generic implementation and with concepts they got manageable. In Rust in many cases you have to use macros. Even if they are good macros they are to my understanding not typed. This is a big drawback to me. The generics are quite limited too. And then Rust has this hidden exception support with panic. This goes on. I have the impression that it wants to fix the same problems like Java but in a faster way. For that the resource model has to be limited which makes it difficult. I am not sure if that is enough to be called a C++ successor. I am much more inclined to think that it will find it's niche like golang.

I think the biggest problem of Rust will be that the other languages will not go away. You have to interface too them easily. But if your resource model is different it gets much harder.

[jacob]

It's about fashion. I have seen that so often. I have seen people writing code in C because they disliked C++. I have seen people rewrite C code because C++ with classes was the new thing. People writing Perl because they liked to be seen as smart because nobody understand their code. Now there a people who like Rust and search things they can rewrite. There will be a new languages after Rust because Rust has blind spots too. That is the way.

This is not some Rust enthusiasts who want to rewrite somebody else's project in Rust just because. This is XCP-ng who decided to rewrite their own code and chose to use Rust for it. There is no fashion nor conspiracy at play.