Programming

Sure, I'm familiar with the conditions under which Javascript was created, but those are all political issues, not technical ones.

If you had to go back and recreate another C++, you would be forgiven for creating a bad language, because making a good, usable language without a garbage collector is really hard, and even moreso when it has to be compatible with C. If you had to recreate Javascript... I would think it would be expected that you don't make a language with the same kinds of flaws JS has today. There were plenty of examples of languages Javascript could have been based off of when it was written (like Java).

Case in point: it took decades for Rust to come around which was the first real challenge to C++. In the same period of time, we saw several GC languages appear (Java, C#, Go, PHP, Swift, Ruby, Python, all younger than C++), all competing against each other. Javascript would have been abandoned if it didn't have a monopoly on web programming.

It may not be perfectly compatible, but being mostly compatible with C was a large part of its selling point when it was originally announced. Without that, it probably wouldn't have seen as much adoption. However, that choice also led to a lot of difficult design decisions which have become a liability today.

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.

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

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.