Firstly, Rust doesn't consider "array" a library type here, in C++ the language has built-in arrays but they're very poor because they are the C arrays - so you use the library feature to get good arrays. In Rust they... just fixed the language, because duh.
Next thing you'll notice is that C++ has lots more of these types, about twice as many. I stopped at C++ 23 because in C++ 26 they added even more. These are a significant maintenance burden and of course having more means in practice maintenance gets worse. But this could be good if these types were all high quality and kept that way.
All of the C++ unordered containers are the same crap hash table design but with slightly different parameters. The Rust HashMap and HashSet are Swiss Tables though they do not promise that and if a better design comes along they will probably switch. C++ can't change the design because the API welds them to a very specific shape for this data structure, a shape which delivers bad performance on any vaguely modern hardware.
std::deque is the most horrible surprise. A modern programmer who has thought about it at all is expecting a type like Rust's VecDeque. Generalise the amortized growable array from the language to use it as a ring buffer. Cheap push & pop at both ends, canonically use it as a FIFO but also practical in lots of other situations. But that's not what std::deque is at all, instead inside it's an array of links to small arrays. On MSVC it's effectively a linked list again because those inner arrays contain only one item due to ABI considerations.
std::set and std::map are very principled red-black trees. I say principled because in practice this is too expensive on modern hardware because (say it with me) it spends too long chasing pointers up and down your tree. Rust's choice here in BTreeMap and BTreeSet packs more data in each "node" on the tree, which makes the big-O worse but the practical performance better. Figuring out how to best do this for the general case is an active area of research but "I bet a pure red-black tree will be fast" is not a good guess for the past several decades.
Finally std::forward_list and std::list are the singly and doubly extrusive linked list types. The thing you most likely have seen in some high performance software is an intrusive linked list, and C++ doesn't provide those. In an intrusive linked list each item in the list itself links to where the next (and for simple double links also the previous) item is, so the item needs to know it's in a list [in some systems more than one list, thus more than one set of links]. C++ provides extrusive linked lists where those links live in a separate object and so the items in the list don't know about this at all. Rust provides only a doubly-linked extrusive list exactly like C++ std::list, but again, this almost certainly isn't what you wanted, you most likely do not need a linked list and if you do have a good reason for a linked list you probably want an intrusive linked list.
