I have 15 years experience as a professional C++ programmer in various teams and companies (and although I don't know 100% of C++17, I consider myself productiv

I have 15 years experience as a professional C++ programmer in various teams and companies (and although I don't know 100% of C++17, I consider myself productive!). When diving into new codebases, the couple of esoteric-used-features-you-did-not-know-existed in C++ was never a big deal. Learning the required C++ features was always a matter of days (because the codebase is full of real examples). Understanding the overall structure of the code, the interactions/dependencies between the components, in what file/directory should go your first feature... this is the hard part. And it's many orders of magnitude harder than learning a couple of new language features. Don't get me wrong, I'd really like that C++ and D be smaller, and I don't like feature bloat. I once wrote a source code processor based on clang, and then you realize how big the language really is (there are many AST node types), and having all your code written in it starts to feel like technical debt. However, I pragmatically have to recognize that feature bloat isn't a real problem for professional C++ programmers (It might be, for compiler vendors - at this point, I'm not expecting any new C++ compiler to be created). PS1: C++ certainly gives you some shiny tools to make interesting messes (I've seen codebases where simply including a header would change the program behavior). This isn't related to the feature count, but rather to the semantic of the individual features themselves, like macros/templates. At least we don't have monkey patching ... PS2: About your Lua example: even without knowing the syntax, can you sincerely have the slightest doubt about what "player:set_pos{x=0, y=0}" actually does?