[interestingcpp]

Simplifying every day usage is entirely a different thing than simplifying the language. I’m not denying the inprovement in usage, just that you should expect the complexity of the language to continually increase because that’s the needs of the c++ community.

[mattnewport]

My question then is why should I care about "increased complexity" by this definition more than about "simpler usage"? Adding well thought out language features that simplify my every day usage is a good thing and the sense in which it increases complexity is not a sense that particularly concerns me. I think C++ is generally making good choices about what features to add. Generic complaints about new features tautologically "increasing complexity" are not interesting. Specific concerns about particular features not carrying their weight in terms of simplifying usage are interesting (and a big part of what the C++ standards process is engaged in).

[corysama]

Agreed. You have to choose between "large scale removal of features from the language" vs "30+ years of back-compat". You can't have both. A huge strength of C++ is it's legacy and the maintainers would be foolish to throw that away in a C++ 2.0 movement.

Instead, they add new features that lets new code be written in new ways without requiring you to toss out your old code. Your old C code is full of mallocs and frees. Your old code still works when you partially update it using the newest features. But, once C++ added new and delete, you rarely ever needed to type malloc or free any more unless you were overloading new and delete. Your old C++ code is full of news and deletes, but new language features added in C++11 made unique_ptr and shared_ptr possible. And, now you rarely need to type new or delete unless you are making your own unique_ptr/shared_ptr variant.

[interestingcpp]

Why would you care? Well the complexity makes tooling difficult, the engineers expensive, and arguably ongoing development could be slower depending on how many c++ features they have to deal with in one code unit. Are these any strikes against the language itself? No, of course not, but one can see why e.g. using go instead might afford more flexibility if the underlying c++ distinguishing features aren’t necessary. The language complexity is still something to consider even if c++ is sufficient.

I am by no means arguing that C++ committees are making any mistakes.

[mattnewport]

I don't think we disagree on much. Jonathan Blow is of the opinion that what games programmers need is a new language designed from scratch, in part because he believes the most viable (and dominant) language used for games, C++, is irredeemably complex. I recognize that there are complexities to C++ but I'm of the opinion that it's been getting better and will continue to do so for games development and that the new features in practice are making the language simpler to use even if technically they are making it "more complex" in the sense of having more features. The tooling is also getting better, despite the complexity, and Clang has played a big part in that. The case for switching to a different language is not compelling to me, especially to a completely new language rather than something with some track record.