XCP-ng Initating Effort To Rewrite Xen Components In Rust

[ssokolow]

Actually Git with all its design glitches is not really a good example. I use it every day and in my opinion there are better user interfaces.

Except that my example wasn't about what had the best user interface, but two potential replacements and which one won out.

You really think that Rust is threatening the jobs of C++ developers? Actually it is more the opposite. If young people don't learn anymore C++ there is less compitition. The C++ code base is so big that it will take decades to fade away.

What I think and what it is or isn't capable of are both irrelevant. What matters is that a lot of C++ developers, rightly or wrongly, feel threatened by it.

Rust is not what I wish for. I simply want more! But actually resource management is not really limiting me. It's testing. Writing tests is not easy and there is the real challenge for me in the economic sense. Getting all the corner cases and distill that in easy to read and maintable code is my goal. Maybe AI can help here.

There's a lot of interest in that sort of thing in the Rust sphere. Aside from type-system tricks like the typestate pattern (enforce correct traversal of state machines at compile time), there's stuff like the QuickCheck and proptest property testing frameworks, Cargo integrations for libFuzzer (cargo-fuzz) and AFL (see The Rust Fuzz Book), and, more recently, the kani-verifier bit-precise model checker.

I forgot about the time I worked with Watcom c++/DOS/ extender. What a frustrating experience many times though I remember fondly for some weird reason. C++ has indeed improved from those times. It still makes sense to move to Rust or something else that is safer though.

I'm using it for C with bits of inline assembly to work around graph.h being thrice the target file size on its own... basically a real-mode "BASIC-scriptable Zip SFX stub" to function as the basis of Inno Setup/NSIS-esque single-file installers (which I aim to fit into 15K or less including zipped control scripting) and some protected-mode support tooling.

If I have something that only needs DPMI, I'll probably use Free Pascal since it benchmarks in the same bracket as Java or C# and the mature, protected mode targets have a Python-esque batteries-included standard library.

[stormcrow]

Except that my example wasn't about what had the best user interface, but two potential replacements and which one won out.



What I think and what it is or isn't capable of are both irrelevant. What matters is that a lot of C++ developers, rightly or wrongly, feel threatened by it.

Your respondent is making the mistake of supplanting personal feelings for an objective argument. His personal feelings is irrelevant to the fact that git has indeed supplanted CVS in the vast majority of projects for version control, or CVS was simply never in the running once git became feature-full enough for widespread use. I also agree the vast majority of reactions to "we're doing this in rust or rewriting this in rust" appear to be people that either never worked on a C or C++ project in their life, or feel threatened by the general trend away from C or C++ for new projects, or living under a rock as far as code security is concerned. There's no doubt at all that there's too much legacy code out there for legacy code base writers to disappear. Hell, COBOL is still a thing and its heyday was in the late 60s & 70s and nearly all of that code base is idiomatic to the proprietary systems they run on (there's no real standardization to COBOL). But, despite the great age of those code bases, they are slowly being isolated and/or replaced. This does require people that not only understand COBOL, but can work out the idiomatic differences between IBM COBOL and any other versions (like gcobol if that path is chosen) . C and C++ coders will eventually become the legacy programmers (code archeologists) COBOL programmers are today. This is not a bad thing. It's the natural evolution of language.

But what a lot of naysayers conveniently ignore is that having a start means that eventually the legacy code bases will fade into disuse. If there's never a start, then those code bases will never fade into disuse and we'll still be finding buffer overflows in 40 year old code after they've already been exploited, just like like we're doing in the present. "Never" is not a future sane people can be hopeful about.

Edit to add: The bottom line is the XCP-ng team has had a rational discussion about their future road map and decided that Rust makes sense from a resource availability and tools capabilities point of view. Language is a tool just like an IDE or debugger. They believe Rust is a better tool moving forward for their project. End of story.

[darkonix]

the vast majority of reactions to "we're doing this in rust or rewriting this in rust" appear to be people that either never worked on a C or C++ project in their life, or feel threatened by the general trend away from C or C++ for new projects, or living under a rock as far as code security is concerned..

It is fascinating that the people in first group that have no logical reason push against change. I understand more the people that actually use c/c++ and feel threatened by change, though I don't agree with them. But I'm scared by the some people think that security is not something that they should care or be mandatory by the tools. All the Rust discussion have highlighted this most irrational of all groups, and dangerous.

[Mordrag]

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.

Seems that you haven't really been coding idiomatic Rust there, but tried to use concepts from other imperative languages that are not really idiomatic in Rust. It would be probably a totally different experience if you would come from a more functional style background. In general I have found it much more appealing to write Rust in a more "functional" style. Meaning using fold, map, filter instead of loops, using tagged unions (enum in Rust) instead of C style enums in structs and using pattern matching everywhere (if let Some(x) = Some(120) is a thing for example). The benefit being that Rust although you code in a more functional style is crazily good at compiling even higher abstractions into efficient code (zero cost abstractions). If you haven't really coded with languages with functional concepts (although that would surprise me given that nearly all languages nowadays have to an extent functional concepts incorporated into them), you will probably have a harder time to learn rust. But the great thing is that learning Rust will then also help you in learning functional languages and it can even make you think more about lifetimes in C++ for example. I bet if you would code in Rust for a while you would have a totally different verdict.


Edit: I think i misread some stuff of you, sorry if i did

[jacob]

That's is interesting. But why people then call it an successor to C++? I think Rust would be less controversial if the marketing would be different.

Literally every single language in existence is "controversial" with someone. Given Rust's uptake both within the FOSS community and by proprietary software developers, it seems to the contrary that there is quite a big consensus behind it among those people whose opinions actually matter. From this point of view, I think we can say that its marketing has been remarkably successful.

[jacob]

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.

Rust is indeed not pragmatic. That's not its point. Pragmatic language are Go, Python or D. They aim to make programming as easy and painless as possible. That's a very worthy goal, but there are some known problems with it, namely when the language does its best to get out of your way, you can all too easily overlook some corner cases, make assumptions that you are 100% certain about but which are in fact wrong, etc. Very often that doesn't really matter, at least not enough to outweigh the advantages in terms of speed/cost of development etc. But Rust is for those cases where it does matter. It's not designed to make things easy, it's designed to make it as hard as possible to fall into these common traps. The price to pay is of course that even good code is harder to write in Rust than in some other languages. That's why Rust will never be the one and true language for everything. For many (and I mean many) applications it's simply not an efficient way to use a developer's time and resources. But something like a kernel, a hypervisor and other things, it's the right way to do it.

I'm not sure what you mean by Rust's generics being limited. Actually they are really quite powerful. One limitation that I know of is that they don't allow higher kind types (but now GATs fill some of the same use cases), but it's interesting to see that comment from a C++ developer when C++ doesn't have anything even remotely similar. Another thing that I'm somewhat missing in Rust are generic modules like in Ada or OCaml, but again, there isn't anything comparable in C++. In fact it seems to me that C++'s templates are not to be compared with generics in Rust at all since they don't even define types, they are in fact macros, similar in their expressiveness (but not their syntax) to Rust's declarative macros. It's basically static duck typing, for better and for worse. I agree that concepts make templates much more manageable but there is a problem in that they don't really work as type bounds in the same way traits do in Rust generics. For example nothing stops you from calling in a template a method that hasn't been declared in the concept. (DISCLAIMER: I looked into this some 2 years ago or so. Maybe now the compilers check it, I don't know, but to my knowledge it's not required by the spec).

[jacob]

It is fascinating that the people in first group that have no logical reason push against change. I understand more the people that actually use c/c++ and feel threatened by change, though I don't agree with them. But I'm scared by the some people think that security is not something that they should care or be mandatory by the tools. All the Rust discussion have highlighted this most irrational of all groups, and dangerous.

I think that those people often mistakenly feel that some projects' goal is, or should be, to prove something about "their" language. They don't get the simple truth that Xen developers, for example, care about developing a hypervisor, they don't care at all about C++ vs Rust.

[patrick1946]

Rust is indeed not pragmatic. That's not its point. Pragmatic language are Go, Python or D. They aim to make programming as easy and painless as possible. That's a very worthy goal, but there are some known problems with it, namely when the language does its best to get out of your way, you can all too easily overlook some corner cases, make assumptions that you are 100% certain about but which are in fact wrong, etc. Very often that doesn't really matter, at least not enough to outweigh the advantages in terms of speed/cost of development etc. But Rust is for those cases where it does matter. It's not designed to make things easy, it's designed to make it as hard as possible to fall into these common traps. The price to pay is of course that even good code is harder to write in Rust than in some other languages. That's why Rust will never be the one and true language for everything. For many (and I mean many) applications it's simply not an efficient way to use a developer's time and resources. But something like a kernel, a hypervisor and other things, it's the right way to do it.

I think you described it better than me. I think it got much easier to develop your own language in the last years. So more languages are popping up. Maybe after that we see a consolidation again.

I'm not sure what you mean by Rust's generics being limited. Actually they are really quite powerful. One limitation that I know of is that they don't allow higher kind types (but now GATs fill some of the same use cases), but it's interesting to see that comment from a C++ developer when C++ doesn't have anything even remotely similar. Another thing that I'm somewhat missing in Rust are generic modules like in Ada or OCaml, but again, there isn't anything comparable in C++. In fact it seems to me that C++'s templates are not to be compared with generics in Rust at all since they don't even define types, they are in fact macros, similar in their expressiveness (but not their syntax) to Rust's declarative macros. It's basically static duck typing, for better and for worse. I agree that concepts make templates much more manageable but there is a problem in that they don't really work as type bounds in the same way traits do in Rust generics. For example nothing stops you from calling in a template a method that hasn't been declared in the concept. (DISCLAIMER: I looked into this some 2 years ago or so. Maybe now the compilers check it, I don't know, but to my knowledge it's not required by the spec).

Actually I still can not use them. Concepts are less than types but more than constraints. So checking if all the code complies is not easy. Especially if you call legacy code. But it is a step in the right direction.

[patrick1946]

Except that my example wasn't about what had the best user interface, but two potential replacements and which one won out.

So not always the best wins?

What I think and what it is or isn't capable of are both irrelevant. What matters is that a lot of C++ developers, rightly or wrongly, feel threatened by it.

Most C++ programmers I know feel threatened by AI. I personally see AI as a chance. For example to find code errors.

[patrick1946]

Seems that you haven't really been coding idiomatic Rust there, but tried to use concepts from other imperative languages that are not really idiomatic in Rust. It would be probably a totally different experience if you would come from a more functional style background. In general I have found it much more appealing to write Rust in a more "functional" style. Meaning using fold, map, filter instead of loops, using tagged unions (enum in Rust) instead of C style enums in structs and using pattern matching everywhere (if let Some(x) = Some(120) is a thing for example). The benefit being that Rust although you code in a more functional style is crazily good at compiling even higher abstractions into efficient code (zero cost abstractions). If you haven't really coded with languages with functional concepts (although that would surprise me given that nearly all languages nowadays have to an extent functional concepts incorporated into them), you will probably have a harder time to learn rust. But the great thing is that learning Rust will then also help you in learning functional languages and it can even make you think more about lifetimes in C++ for example. I bet if you would code in Rust for a while you would have a totally different verdict.

I think that ideas from functional programming get incorporated into other language are older than Rust. After all the years I think pragmatic languages are the best tools but that is only my personal experience.