Here’s a 249-page book “just” about atomics and locks in Rust. Does a book this large about only one aspect of Rust prove that it’s a terrible language? No

If that book was about a million ways of how to just use atomics in Rust, then yes, that would be potentially bad. But SURPRISE SURPRISE, it's not. As you can see for yourself.

Not sure what you were getting at there. Even hard C++ copers don't attempt to argue against the fact that C++ is huge, and not only that, it's the biggest language around by an easy margin (this can be roughly and superficially measured by comparing spec sizes).

It's not the size, but rather everything on top of it, and contributing to it, from general incoherence to bad design to countless misfeatures, that require non-trivial argumentation.

That is not just a book about how to "cut potatoes". That is "A Creative Cooking Guide for Exercising Knife Skills", using potatoes as a medium. Similarly, your Rust book is an book on concurrency using Rust as a medium, as per the title: "Low-Level Concurrency in Practice". Both are complex topics, and both have picked a medium. Thus, they do not necessarily reflect on the underlying complexity of the medium, though concurrency in Rust is a complex topic due to the fact that the core language itself does a lot of work to make it "safe". Async would probably be an even better example of that.

However, in the case of initialization in C++ and in the case of move schematics in C++, these are topics that are complex because the core language has been accumulating complexity for a long time, and because the language designers cannot afford to break backwards compatibility. Which makes implementing and using move-schematics in C++, as an end-user of the language, much, much more complicated than in a language like Rust, that did not have to bolt this behavior on top of an already complicated language. Similarly with initialization, where C++ has accumulated many, syntactically overlapping forms of initialization, for both member and non-member variables variables

There's a book about 101 ways to cut potatoes. Perhaps that could be a real mike-drop bit of evidence that we shouldn't be cooking potatoes.

This would be a valid argument if to read someone else's recipe you'd need to know every way of potato cutting they might use.

The problem with C++ isn't that you can't use it in a good way. The problem is that you can use it in a million different ways. The best way for your application is often not readily visible and reading someone else's code might be really difficult because they have a weird favourite way of doing things that you might not know.

Python does that quite well (it's got other failings, but in this regard it's good):

There's a class that's just called List and there's a literal that creates an instance of it: []. It's implemented using an array list, since that's the most sensible options for most list use cases. If you need another type of list, they are still available, but the default implementation is clearly visible and uses a sensible implementation.