I think you're implicitly saying that Rust solves the problems in the article, and so migrating C++ projects to use Rust is a path forward. However, the blog author's first example was implementing a "contiguous circular queue", so you should try to do that in Rust. Of course Rust already has VecDeque<T>, but then C++ already has std::deque<T> too (although not promised to be contiguous). So the exercise is to implement your own, from scratch, without just wrapping a type that does the dirty work for you.
If you look closely at the implementation details for VecDeque<T>, you'll find a lot of complexity you might not expect. To do it efficiently and correctly, you need to work with unitialized memory. So there will be unsafe blocks in there. A VecDeque<T> is built of a RawVec<T>, which uses a Unique<T>, which finally has a pointer, but also contains a magical PhantomData<T>. Look at the code [0] [1] [2] [3], look at the implementation details, read the comments, and assess for yourself if it's easier or harder than C++.
Later in the article, he talks about exception safety. For something like a container, the most likely exceptions are that you've run out of memory, or you can't move/copy/construct an item in the container. I'm honestly not sure how Rust's builtin containers handle these problems. (Panic?) But if you're comparing the two languages, the apples and oranges matter.
All of this to say that Rust is not simple either. You can program Rust by using its standard collections, and you can do the same with C++. If you try to implement those collections, say for learning/teaching data structures, both languages seem painfully complicated to me.
> Later in the article, he talks about exception safety. For something like a container, the most likely exceptions are that you've run out of memory, or you can't move/copy/construct an item in the container. I'm honestly not sure how Rust's builtin containers handle these problems. (Panic?)
As I understand it yes, the containers will panic.
Part of the discussion about using Rust in the Linux kernel is what to do about failed memory allocations. And this is a problem more generally for Rust usage in embedded systems.
So there may need to be support for alternative allocators or something else.
Part of the key is that they’re not really “built in.” They’re in the standard library. When you’re in those contexts, you just don’t use the standard library. Problem solved.
Now, the standard library is also getting support for these things not panicking on allocation failure, and when that’s ready enough for those that want it (Rust for Linux has pulled the changes into their tree, in my understanding) then they could use them.
(I work on embedded systems with no dynamic allocation, Rust is great.)
If you look closely at the implementation details for VecDeque<T>, you'll find a lot of complexity you might not expect. To do it efficiently and correctly, you need to work with unitialized memory. So there will be unsafe blocks in there. A VecDeque<T> is built of a RawVec<T>, which uses a Unique<T>, which finally has a pointer, but also contains a magical PhantomData<T>. Look at the code [0] [1] [2] [3], look at the implementation details, read the comments, and assess for yourself if it's easier or harder than C++.
Later in the article, he talks about exception safety. For something like a container, the most likely exceptions are that you've run out of memory, or you can't move/copy/construct an item in the container. I'm honestly not sure how Rust's builtin containers handle these problems. (Panic?) But if you're comparing the two languages, the apples and oranges matter.
All of this to say that Rust is not simple either. You can program Rust by using its standard collections, and you can do the same with C++. If you try to implement those collections, say for learning/teaching data structures, both languages seem painfully complicated to me.
[0] https://doc.rust-lang.org/src/alloc/collections/vec_deque/mo...
[1] https://doc.rust-lang.org/src/alloc/raw_vec.rs.html#52
[2] https://docs.rs/ptr/0.1.0/src/ptr/lib.rs.html#39-47
[3] https://doc.rust-lang.org/src/core/marker.rs.html#679