The first commits to IncludeOS were 2014, when Rust was in a high state of flux; before the 1.0 release. So I'm certainly not surprised given the historical context of the two projects.
Rust has some cool features, but believe it or not, C++ is still a popular language and people continue to develop projects that are older than Rust. So even if you're of the opinion that C++ is entirely deprecated by Rust, we're not going to stop the entire world and rewrite every C++ project in Rust.
But good news! You can run your Rust apps in a Rust-based unikernel OS [1]. Since these OSs are meant to run in containers, the ecosystem is big enough for both and we don't need such shedpainting conversations.
Memory and thread safety properties can be achieved in C++ by operating at a higher level than C with mature, well-debugged, well-optimized libraries. No pointers means no pointer errors.
Integer overflows are equally possible in Rust and C++. Both offer debug build modes that can watch for those.
Use after free can be perfectly well expressed with C++ references, or invalidated iterators to standard library containers.
> Integer overflows are equally possible in Rust and C++.
In C++, unsigned integer overflows can often be leveraged into out-of-bounds access; in safe Rust, they cannot.
Eh, not to the extent that Rust does. It’s still reasonably easy to get use-after-frees by using a value that has been moved or destroyed.
> Integer overflows are equally possible in Rust and C++. Both offer debug build modes that can watch for those.
In Rust the behavior is defined regardless of signedness.
I have the same discussion with people who insist unsigned types in C++ or C are safer than signed types because of the UB boogeyman. They only demonstrate their own limited understanding.