It is PL/I style of huge, however the more time I spend in other ecosystems, they aren't that small either.

I would fail a C++20 pub quizz, but I surely wouldn't fair much better if the questions would be about Java 17, Python 3.9, C# 10, .... including runtimes and standard libraries during their existence.

>"I would fail a C++20 pub quizz"

Same here. It does not preclude creating high quality products though. I learn / fish out of my memory features on on need basis. Due to writing software for the last 40 years I have very good understanding what should be available and where but remember everything in multiple languages in detail is pure insanity. And in my opinion that knowledge is not what defines being good programmer.

The thing I find almost impossible to store in my own memory is which C++ version a feature was added in, so when working on a C++14 codebase, I write class template parameter deduction dependent code and then have to check CPP Reference to see why I was wrong. I agree that memorizing gobs of this stuff isn’t important.

Same here, but also applies to other languages as well, sigh.

I think the main difference is languages like C# don't have the foot guns that C++ does. You can start using them and write reasonable code straight away. I always felt with C++ you need to know a lot before you write your first line of code.

They do actually, like semantics of variables declared in foreach loops, how closures are captured, some of the runtime changes that require appconfig settigs for the old behavior, for example.

I've never used a programming language that is as hostile to programmers who have bugs as C++.

C is worse.

I'm not sure that's true. C's simplicity helps it out here.

Ultimately when everything is on fire, what's running isn't C or C++ but machine code. So, worst case in either scenario you're looking at the machine code.

But the correspondence between your C++ and the machine code is far worse than for C. In your C program a lot of closing curly braces don't result in any code being emitted, but in C++ lots of the machine code can be attributed to the innocuous looking closing curly braces. Every local leaving scope calls its destructors.

C++ doesn't actually "de-sugar" syntactic sugar in a consistent way. So, while you know your ranged for is in some sense sugar for a traditional C-style indexed for loop, you can't show that loop and aren't intended to. But this means a further loss of correspondence. In both cases the compiler is going to emit the same code, it's not stupid, this is the same operation, with more or less sugar. But the machine code looks a lot more like the indexed for loop.

I like for each type loops, iterator adaptors, and so on, if I never write another traditional indexed for loop in my life that'd be fine, but if the world is mysteriously on fire and I need to understand why, the nice sugar is not a good model for what the machine was actually doing.

Also, template meta-programmed constants. Your C++ program may have a difficult to understand bug at compile time. Yes, the C-pre-processor is terrible here, but that's technically shared by both languages, I'm talking about constexpr template madness. For example maybe at compile time your C++ program should parse JSON and behave differently based on the results. That's a real thing.

C's supposed simplicity is wholly a mirage. "Limited" would be the accurate description.

Everyone's chief exposure to complexity is the code written in the language, where the complexity comes from the problem domain and everything it takes to wrangle that complexity with what the language has to offer. By that measure, C's sharp limits mean that your exposure to complexity is much greater in a C program than in a C++ program.