> If you're a C programmer and want to avoid the GC, there's nothing to be viral.

What you're suggesting is the moral equivalent of "it's easy to avoid diseases, just avoid contact with those infected", or "it's easy to avoid allergens, just avoid foods you're allergic to", or "it's easy to avoid contamination, just set up a cleanroom", or "it's easy to write deterministic code, just avoid randomness", etc.

Yes, there are things that are easy to achieve in the vacuum of outer space, but that's not where most people are interested in living.

I often hear a lot worse :-) No worries, it doesn't bother me. What pleases me are the people who use D, like it, and tell me they make more money using D because D is much more productive to write code in.

D also attracts expert programmers who are very comfortable using the GC when appropriate, stack allocation when appropriate, malloc/free, even ref counting. These are just tools in the toolbox, like I use socket wrenches, end wrenches, box wrenches, crow foot wrenches, pipe wrenches, monkey wrenches, etc. I don't try to use socket wrenches for everything.

BTW, the GC makes managing memory in compile time function execution trivial. Something that non-GC languages struggle with.

It's better than the feedback I would have for, to give an example, Bjarne Stroustrup. Bjarne has spent so far as I can tell almost all of his adult life on C++. It's a huge bloated mess, and though there are many other guilty parties I don't think I can even say he was a good influence.

> Because at the scale many companies use C++, the additions into ISO C++, for how bad WG21 process currently might be, don't land there because a group of academics found a cool feature, rather some company or individual has seen it as a must have feature for their industry.

Maybe it's just me but, sorry, I cannot parse this sentence.

> Why is a big number of features a problem? You can ignore them if you don't like/need them.

You 100% cannot do that. I mean, you can if you're writing some toy project just for your own use. But as soon as you start interacting with other programmers, it's inevitable that some will use some other subset of language features.

> Can you briefly explain which features can be thrown out and language will not miss a lot without them?

I don't think that it's controversial that C++ is a huge language with many features, and I doubt I'm the best person to rehash that. One often quoted example is the multitude of ways to initialise a variable (Foo x = y; Foo x(y); Foo x = {y}; Foo x{y} and for default initialisation Foo x; Foo x = {}; Foo x{}; Foo x() (not really - that's the most vexing parse); Foo x = Foo()). There's multiple syntaxes to define a function including auto and decltype(auto) return types. There are const, consteval and constexpr - you may know the difference but I've forgotten. There are so many templating features that I wouldn't know where to start. Concepts are layered on top of that - which are useful and a good idea but no denying that it's layering extra complexity on top (which can be said for many C++ features). I've really just scratched the surface.

The thing is, I learned C++ over 20 years ago, when the latest standard was C++03 (which was essentially the same as C++98). Even at the time, C++ seemed like a bit of a chunky language (e.g., compared to C or Object Pascal - languages tended to be simpler back then), but it was achievable to mostly understand it all. But each revision that passed has added a huge volume of features. So I really feel how big C++ is because it's even big compared to (an older version of) itself. I've mostly kept up over the years but I can't imagine how I would properly learn the language today from scratch - I feel like you don't really stand a chance unless you've also been closely following it for decades.

I'm well aware of those, and they obviously don't fill the gaps here.