Notably:
• Rust doesn't have inheritance. This makes a lot of basic C++ programming patterns unfit for Rust, and prevents 1:1 translation of C++ to Rust.
• Rust's generics may look like C++ templates, but they're not. Rust's macros behave more like C++ templates, and generics are closer to C++ concepts, but neither is a close match. C++ programmers are generally flabbergasted how hard is to make a function that takes any integer type in Rust.
• Even though Rust copied C++ moves, and has "RAII", the way these are used in practice ends up different due to having opposite defaults and different guarantees. Rust doesn't have constructors. Its closest equivalent of exceptions is for a different purpose. Rust's types are always movable, don't have meaningful addresses, can't reference own fields. Even C++'s std::string is hopelessly incompatible with Rust.
C++ has two string types, because of C legacy. Rust has two (and more) string types to express different modes of ownership. C++ is a complex language, because they keep adding more ways to initialize a variable. Rust has exactly one way. But Rust has many other features, mostly in its type system, to define thread-safety, memory-safety, and memory management in detail that is beyond what C++ can express. So "but they're both big" is glossing over all the reasons why.
However, C happens to be almost a clean subset of Rust. You can take a C program and translate it line by line to Rust. It won't be idiomatic, but may be easy to refactor into proper Rust. That's generally not true with C++, which requires rethinking everything from basic idioms and constructs to the overall architecture. This is why Rust struggles with GUI libraries, and the best-supported native toolkit is from C.