I ran across this a couple of days ago, but it's the summary email that resulted in me actually replying. Most of the decision between the languages is personal, and there are considerations to be made. If you know neither, both of them have sharp edges (but Rust is far more telling "what went wrong"). If you know one, and are coming to the other (like I'd suggest many did with C++ then coming to Rust), then you'll have a bias (at least at first). My journey started off not like Rust at all (but it was pre-1.0, so every language change resulted in me having to re-learn something while working in Go, C++, Python, JavaScript, and Lua), but as it stabilised (~2015), it grew on me (though there are still a lot of libraries I call from Rust that are written in C++ and accessed via a C library!).
I'd say C++ seems to give you more control, but it's an illusion due to Rust's implied safety. I say "implied safety" because unless you explicitly opt into the unsafe code regions (like most of my code does for speed), you are safe, provided the code you use is safe (beneath the hood a lot of safe code uses unsafe methods to get you speed and access -- they are usually checked and made safe, but they're still written in unsafe blocks or functions!). It's a bit of a nitpick, but to me it's an important one. In C++ I leave comments for people to find the scary code (because often it's hard to determine if (**pObj) is unsafe or just getting what the pointer to a pointer is pointing at to use it, let alone grok it quickly); in Rust unsafe fn prevents me from having to explicitly write "HERE BE DRAGONS" (though I do that anyway when it's particularly scary that can go wrong).
Borrow checker issues aside (they're known and being fixed(?)), you can do almost everything insane you want to do in C or C++ in Rust. The one exception I've come across thus far is hotpatching (which is basically irrelevant for the reasons you're asking), and can be done in ways that aren't ideal (though the stability concerns in question for real hotpatching are terrifying, and outside of a virtual machine, like BEAM, it's not always a good idea -- unless you like coworkers screaming at you).
If the question is "which has more features that I can exploit for ", Rust can use C libraries, and C++ can be built into C libraries to be used in Rust. I've moved from C++ to Rust (and Go) in most of my personal and private projects because I prefer the safety the compiler offers me. I now ask myself, "should I be using unsafe?" (Okay, I don't do this enough, but I should, and it's a reminder every time I type unsafe that I'm the kind of person who writes way too much of it; this reminder has resulted in me writing more safe code (though it usually gets rewritten for speed later).) The advantage of this is you start off writing sane code (that isn't super performant) first. You know it works, you know what it does, what it's meant to do, and you can maintain the API (at least externally). You can then write a faster version, wrap it up behind a feature (as a guard), and bam, best of both worlds.
As for the video/text debate, I query the video part. Not because there aren't multiple kinds of learners (visual, audio, etc.), but because the video requires you to split your focus in a different way. You don't "pause" a book like you do video and audio, and they can give you information that's an aside; it's a bit like reading a map compared to relying on a GPS, where one requires you to process the information and store it in your memory (the map), the other feeds it to you and reduces how much you need to use that part of your memory. Sure, there are theoretically upsides to the GPS in this (and thus so too the "video"), but I'd prefer to buffer the information in my brain so I can mull over it, and fall back to the "look, cover, guess, check" style of learning. It's a personal preference, sure, but I can't help but feel that better exposure is more helpful. It also means I can review it in ways that are frustrating with a video.
Regardless of the learning angle you choose, be aware you'll be spending a lot of time reading. If for no other reason than it's very unlikely the API is going to be turned into a useful audio or video resource, and the constant moving target of all of the crates (and their documentation) means that short of generic text-to-speech, you won't see much; I don't agree with the way it was put before, but reading and constantly learning is the way of information technology.
For visual things, like visualisation, game design/engines, and the like, video supplements can be great. I'm not saying they're bad, but in reality I question how a screenshot isn't almost always as good for the basics -- only for animation do you really need more for verification.
Seriously, though, learning a programming is about reading (intensive reading) and doing. Watching videos is only useful in the most rudimentary sense for introductory purposes. If you are trying to break into software development, and you don't like learning through reading, you might want to consider a different profession. I can't imagine ever being successful by wanting to learn programming through video tutorials (primarily).
