XCP-ng Initating Effort To Rewrite Xen Components In Rust

[ssokolow]

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.

As Alex Gaynor wrote, Modern C++ Won't Save Us. What makes Rust special is that C++ has a "we can make it better" philosophy while Rust has a philosophy that "If there's a hole and it's not coming from one of the "human must audit" constructs inside an unsafe block, then it's a bug in the language/compiler and our job to fix it".

To retrofit C++ to achieve that would change it so much that it effectively wouldn't be C++ anymore, but some blend of "uglier Rust" and "painful-to-write C++".

Rust gets away with it because you expect to have to put the work in to add all those extra safety annotations when writing a binding for a C or C++ library from another language. Attempts to convince C or C++ programmers to add more safety annotations (eg. through linters like splint) have failed.

[ssokolow]

Poke poke. Unapproved.

[patrick1946]

You're exactly right about Rust's relationship to C and C++. C++ was "Here at Subversion, we're making a better CVS" while Rust is "We still need something to serve CVS's role, but let's go back to first principles and try again". (Bearing in mind that, in many of its design decisions, Rust is an ML-family language like Ocaml with a coat of carefully selected C++ syntax elements to make it friendlier to mainstream programmers.)

That's why the semantics are so different. It's more of the lineage that began with ML in 1973 than of the ALGOL 68 lineage like C is. The Rust compiler was even originally written in Ocaml before it became self-hosting.

That's also where it got things like let for variable declaration, postfix type annotations separated by colons, 'a for lifetimes (Ocaml's equivalent to <T> is 'a and lifetimes in Rust are a special kind of generic parameter), Option/Some/None (option in Ocaml), match, fn (fun or function in Ocaml with fn being more from fn(x) in math papers), -> and => (just -> in Ocaml) for function returns and match arms, and () as the void return type.

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.

C++ templates are dynamically/duck-typed (eg. SFINAE) and Rust developers wanted statically typed generics. Among other reasons, to make error message complexity more manageable than "On second thought, I'll just stare at the code some more". Rust's macros are token-based and more like C++'s templates and they're what you're supposed to use when you want duck-typing. (Rust's declarative macro syntax is just a variant of their match syntax with some extra syntax like $argument to keep things clean when you're writing code that generates code.)

Templates are not types, they are generics. The use types and variables to archive compile type customization like you can do with constexpr. With Concepts you know have a higher order entity. So what types are to variables are Concepts to templates. But I see you intention and I agree they made templates harder. But with concepts it should be much easier. So I see no point in constrainted generics in Rust. Especially the missing variadic support is not nice. I know you can use macros for that but .... ;-)

Rust's panic! is equivalent to C's abort() and the top-level Cargo.toml (Makefile) has final say on whether panics unwrap or abort. They weren't catchable in Rust 1.0 and catch_unwind was added specifically for translating unwinding panics into error codes when writing a Rust library which exposes a C interface. Panics are specifically meant for handling programmer errors in the same way abort() is (eg. they're the building block for Rust's asserts) and you will not be well-received if you treat them as exceptions. (I still don't trust the competence of author of an executable parsing crate which I managed to induce to panic! rather than Err(...) on untrusted input and that was about not being careful enough about "Untrusted input should never be able to induce a panic. That's a DoS vulnerability.", not about "panics are for programmer errors/bugs, not for user errors".)

It is the same way I use exceptions. Something you cannot handle locally like missing resources. For example if you start an action which eats all your resources it is nice that you can abort it without crashing. Exceptions are working well for me in TDD too.

Rust was explicitly co-designed with the Servo browser engine and evolved around the use-case of replacing C++ in Firefox. Google has been using it to replace C and C++ in Android (not Java) and they're quite pleased with the results. The Chromium team are gearing up to use it in Chrome. Patches are landing in the Linux kernel to support drivers written in Rust and Asahi Lina is very happy with the experience of using it to write the GPU driver for M1 macs. I'd say that's pretty strong evidence in support for it being suitable for replacing C++ in many use-cases.

I read an interesting article about servo. To my understanding it was never designed to replace gecko but maybeI got it wrong. And if it would be so successful why development slowed down so much. Otherwise C++ is used in many areas and over time different languages took over in some areas. Sometimes because C++ as a language cannot do everything well. In other areas because there is a very conservative stream inside the community. I really hope that resource management gets even better. It is not important for my field but it would be nice. But not at the expense of other useful pattern like dependency injection etc.. What is much more important for me is that concurrent programing gets easier.

[mdedetrich]

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.

Toi be honest you can argue that about any new language, almost always part of the reason is because of perceived deficiencies in current languages/tooling (i.e. "dislike"). In any case the main driver for Rust wasn't some irrational dislike of C++ but rather wanting a C like language that had compile time memory guarantees. Actually in Rust's early days it was closer to Go, i.e. it achieved this memory safety via a GC. However the designers of the language realized that GC was largely not necessary, C++ didn't really come into play here.

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.

Rust is not marketing itself this way, C++ programmers who are feeling the heat from Rust due to competition are the ones saying this.

[mdedetrich]

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.

This was true but is now being solved with OCaml Multicore (you can look it up)

[lowflyer]

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.

AMEN!

(It rarely happens that I literally "like" all posts from a single user in a thread.)

[ssokolow]

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.

Because it can serve the same roles without being a refinement of the same design, in the same way that git supplanted CVS despite having a radically different design.

That's also part of the reason many C++ developers feel threatened by it. It has the potential to displace C++ but in a way that a lot of their hard-won knowledge is irrelevant to.

Templates are not types, they are generics. The use types and variables to archive compile type customization like you can do with constexpr. With Concepts you know have a higher order entity. So what types are to variables are Concepts to templates. But I see you intention and I agree they made templates harder. But with concepts it should be much easier. So I see no point in constrainted generics in Rust. Especially the missing variadic support is not nice. I know you can use macros for that but .... ;-)

Some of it is just that, like WebAssembly and various other projects Mozilla has had a hand in, Rust development takes a 'release a Minimum Viable Product and refine based on real-world use' approach.

Variadic support in a way compatible with the goals they started out having as primary is a difficult thing to design correctly, with surprise gotchas lurking in attempts to implement it. That and the prioritization of things that are more difficult to provide workarounds for without compiler support are why there's been an RFC since 2014 but we don't have them yet.

It is the same way I use exceptions. Something you cannot handle locally like missing resources. For example if you start an action which eats all your resources it is nice that you can abort it without crashing. Exceptions are working well for me in TDD too.

I suggest reading Exception Handling Considered Harmful by Jason Robert Carey from 2005. The gist is that Exceptions embody a fundamental perception that failure can always be handled by a transaction-rollback model, and they interact poorly with (or, more correctly, ignore the existence of) parallel and concurrent execution.

Aside from that, it's funny you should point to them because error handling was a big part of why I migrated from Bourne shell script to Python (try/finally being superior to trap, though there were tons of other reasons too) and then from Python to Rust (Result being superior to try/except/finally) for my "shell scripts".

My biggest problem with exceptions and one of the biggest reasons I use Rust for "shell scripts". Unchecked exceptions require you to Read The Source to know whether a function is fallible. Rust's monadic error handling is basically Java's checked exceptions done properly (i.e. not just being a sidecar outside the type system) and a language which pushes you to use it for anything that isn't "Programmer bug. Internal state must now be assumed to be undefined." has the effect of surfacing all relevant control flow paths in the function's signature.

I read an interesting article about servo. To my understanding it was never designed to replace gecko but maybeI got it wrong.

Servo was designed as a research project so, no, it was never designed to replace Firefox as-is, but many of its components were transplanted once they were mature. (eg. Firefox integrated the Stylo CSS engine from Servo as "Quantum CSS" after two failed attempts to write a multi-threaded CSS engine in C++.)

And if it would be so successful why development slowed down so much.

Because incorporating components like Stylo into Firefox was followed shortly after by Mozilla encountering financial rough seas that led to several efforts being closed down to trim the budget. The team dedicated to working on Servo got axed during that belt-tightening. They are still working to rewrite Firefox components in Rust in a less visible manner though. (Their Oxidation page is a bit stale, but shows what the state of things was in 2020.)

Otherwise C++ is used in many areas and over time different languages took over in some areas. Sometimes because C++ as a language cannot do everything well. In other areas because there is a very conservative stream inside the community. I really hope that resource management gets even better. It is not important for my field but it would be nice. But not at the expense of other useful pattern like dependency injection etc.. What is much more important for me is that concurrent programing gets easier.

The divergence fundamentally boils down to how the two languages cope with undecidability. When the C++ compiler can't be sure if the code is valid or invalid, it trusts the programmer. When the Rust compiler can't be sure if the program is valid or invalid, it rejects it, except for a specific set of constructs that are gated behind the unsafe keyword, which can be used to construct new primitives for the safe subset of the language.

That and the concept of separation logic is also where most of Rust's defining characteristics prove themselves to be mandatory.

Rust has demonstrated that you using a type system as a vehicle for separation logic works, even in imperative languages, and it's nothing as arcane as those immutable functional predecessors would suggest. It did this by making sure the language defines a type system that helps you, by making sure core properties of soundness can be expressed in it.

• soundness requirement for memory access: lifetimes
• soundness requirements for references with value semantics: &/&mut
• soundness requirements for resources: Copy and Drop
• making sure your logic is monotic: traits instead of inheritance, lack of specialization (yes, that's a feature).
• (notably missing: no dependent types; apparently not 'necessary' but I'm sure it could be useful; however, research is heavily ongoing; caution is good)

This allows the standard library to encode all of its relevant requirements as types. And doing this everywhere is its soundness property: safe functions have no requirements beyond the sum of its parameter type, unsafe functions can. Nothing new or special there, nothing that makes Rust's notion of soundness special.

Basing your mathematical reasoning on separation logic makes soundness reviews local instead of requiring whole program analysis. This is what makes it practical. It did this pretty successfully and principled, but did no single truly revolutionary thing. It's a sum of good bits from the last decade of type system research. That's probably why people refer to it as 'the soundness definition', it's just a very poignant way to say: "we learned that a practical type systems works as a proof checker".

-- HeroicKatora @ https://www.reddit.com/r/cpp/comment...afety/j4ks225/

[patrick1946]

Because it can serve the same roles without being a refinement of the same design, in the same way that git supplanted CVS despite having a radically different design

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.

That's also part of the reason many C++ developers feel threatened by it. It has the potential to displace C++ but in a way that a lot of their hard-won knowledge is irrelevant to.

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.

I suggest reading Exception Handling Considered Harmful by Jason Robert Carey from 2005. The gist is that Exceptions embody a fundamental perception that failure can always be handled by a transaction-rollback model, and they interact poorly with (or, more correctly, ignore the existence of) parallel and concurrent execution.

Yes, you should not handle common states with it. So I would nor compare them to the normal error handling of Rust. There is std::expected for that. It's for really unexpected errors. In Rust you would most probably panic in that case.

The article points to bad code which is not using RAII which will bring you in trouble. Yes, I have seen this code very often, especially from C with classes programmer. But that code is troublesome without exceptions too.

I hope that Rust is successful. I hope what we get even something better. The problem with computer language is that they are designed by smart people who luckily don't know all the problems. If they would do they would stay away.

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.

[darkonix]

(For my DOS retro-hobby project, I've made it a rule that mandatory dependencies for the build process must either be vendored or coming from the Open Watcom C/C++ installer and the Watcom Make file must Just Work™ without extra setup steps.)

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.

[oleid]

And then Rust has this hidden exception support with panic.

Well, there are panics, for sure. But they are mostly relevant in prototyping (where you unwrap a lot) or in certain special conditions where panic-ing makes sense (because of a really un-recoverable error). If you use panics for other things you're doing something very wrong.