In my early 20's I got the appeal of that I think. I wrote a lot of C++, learned all the (then) new features and design patterns. I had a bunch of C++ books covering various advanced topics. I felt like a rockstar implementing ultra-sophisticated generic libraries.

I think I remember what the breaking point was for me. I had a custom serialization format (something YAML-like, because of course I had to implement my own custom format) and I wanted to pretty print it. I needed to implement some kind of indentation routine, you know, add a number of spaces at the start of a line depending on the current nesting level.

I wrote an indentation class that was fully generic. As in, the whole concept of indentation was abstracted away, I wasn't dealing with line buffers and characters, I had generic streams of objects and everything was templated and Boosted to the max. Must have taken about 20minutes to compile on the CPUs of that time. I was proud of my mad cpp skillz too.

And then the absurdity of it struck me. Over the next few years I found myself returning to the simplicity of C more and more (not that I would recommend C as a replacement for C++ in the general case, mind you).

Often when I read C++ discussions these days I think I detect the same kind of hubris I used to experience. Just writing ultra-complicated code for the sake of some perverted notion of purity and elegance.

So when you mix that mindset with the "and the kitchen sink too" ethos of the C++ language committee, you end up with the unmaintainable monstrosity that's modern C++.

You just described me in my 20s as well. I used to revel in my knowledge of C++ minutiae and being able to quote parts of the standard and recognize obscure undefined behavior.

Then I started a company and hired people to work with me and it hit me just how much of an absolute waste of time it is to know that stuff. It doesn't translate or generalize well, most C++ is a special kind of complexity that is only relevant to C++, and then when you hire people you can actually assign a dollar cost to the complexity and that cost is simply not worth it.

I still use C++ at my company, but I now use a very simple and straight forward subset of it, basically along the lines of C with classes and namespaces. No more boost, no more elaborate SFINAE, no more writing things to be so generic and obtuse and avoiding parts of the language that are too abstract.

In that vein I also avoid all of the mess introduced by C++20. Concepts were a missed opportunity, modules are beyond useless, and the fact that C++20 has both coroutines and ranges just shows how the language is designed in a Frankenstein manner. A good solution for coroutines would make the use of ranges unnecessary, and a good solution for ranges would make coroutines unnecessary.

Instead C++20 provides half-assed implementations of both.

I find myself largely agreeing with you about the hubris and complexity behind most c++14/17/20 discussions today. and often feel adding complexity for the sake of intellectual satisfaction is pointless and should be avoided.

My view is that we mostly read code a lot more than write it and code is basically the low level fabric on with we build higher level abstractions like business logic (except for some ultra specialized cases like shaders or vector assembly). My problem is that any senior engineer shouldn't have to waste brain cycles figuring out the language antics when reading code because that takes you away from the reality you really want to get to (the business logic or the intent of code). for a reasonbly senor coder the language really should be out of teh pecture. these antics often end up wasting attention and sometime resources because likely somebody would use that code in a way its not intended and it will have a subtle failure like using extra resources etc

PS: apologies for misspells in above para, was hoping to make a point.

I believe that deep, down its a question of identity and incentives. The right thing to do is reduce complexity.

But the thing that optimizes for nerd status and job security and resume building is to increase complexity, because most people cannot appreciate the sophistication of simplicity in some technological niche, and it is not easily communicated.

And then there is the question of what gives you joy? I find that for most coders, their primary motivation is not to solve a customer problem in the quickest, simplest and most efficient way, but to challenge themselves with riddles and learn new tech and follow fashion. This definitely varies by culture - Golang and Haskell are on opposite ends in that spectrum.

Overcoming delusion means to exit one's own mind and observe the real world. Looking at useful and well-made software, in which language is it implemented in? A Haskell fan will have no trouble talking for hours about how its concepts are superior. But he will not notice that there is barely any popular software written in Haskell out there, and he will not understand what that implies.

You hit the nail on the head I think. A few years into my career I was enamored by learning new programming languages, in particular functional ones. I was fully drinking the koolaid, too - pure functions and immutability would surely make writing web crud a blissful experience, right?

At some point I realized that the nice examples from the books never mapped to the real world as cleanly. Exceptions were pretty useful, local mutability made lots of things easier, and category theory has no place in calling JSON apis over http.

I think a great number of talented programmers never learn that lesson, and continue futzing about with theoretical purity for its own sake.

On the other hand there is value in learning different languages and concepts, and possibly applying them in your day to day job if it makes sense. It makes you a better programmer. But one is a means to an end, and the other is... I don't know, a philosophy? L'art pour l'art?

"But the thing that optimizes for nerd status and job security and resume building is to increase complexity, because most people cannot appreciate the sophistication of simplicity in some technological niche, and it is not easily communicated."

I think you're on to something there, except for the "job security" part. I've met very few people in tech who are concerned about losing their jobs, and fewer of them would make things much more complex---they didn't have the skills.

In fact, most of the majority I have known who produced complexity were optimizing for nerd status and resume building, but would quit rather than maintain their own complex code.

you can limit your code to a subset of c++, make it like a c with free ctor/dtor and simple classes, then it's not that complex.

I think this kind of philosophy is what ended up driving Go's simplicity.

Less infatuation with the tool, more focus on shipping maintainable code the first time.

And you can't really have a sane conversation with these guys either. I've never met a more arrogant programming community than the c++.

I wanted to learn more low level programming when I was a C# dev, and coming from an OOP background, I chose C++ (also I had encountered c++ in school as a first language) . Man, was it humiliating asking questions even on stack overflow. Apparently everything is obvious and I'm an idiot.

In any case, I dropped C++ (not because of the obnoxious community but the language felt so poorly designed, coming from C#) and turned to C. Its been so far an amazing experience learning from C community. They are deeply insightful about computers and genuinely willing to help new engineers. Very experienced and very high calibre c engineers were helping me out without trying to show off how much smarter they are than the rest of the world despite being clearly far better and smarter than I am.

There are a lot of hardware engineers at my company that more or less occasionally use Python or C# to get their job done. I understand that those languages are the better choice for them and gladly help them with getting C bindings done for the odd library in our industry, and to understand some low level concepts such as CPU cache when they run into problems due to those.

I turned away from the C++ unity towards the Rust community because I saw the same issue as you, and am very happy about that decision.

It is somehow ironic to read this, given the heat given to newcomers on comp.lang.c and even the moderated one on Usenet.

I'm sorry, but using stackoverflow as a proxy for any "community" is giving that s(h)ite too much credit. It is infected with arrogant assholes regardless of the field.

(I guess I'm old and misanthropic but I would not seek out answers by asking on the internet, but instead by reading one of the many excellent books on C++. It's not some obscure hobby where you need the collective wisdom of old hands.)

Now, I've been doing C++ for 20+ years, and the only real way to get help/mentorship in my experience is people you work with. There are too many ways to do any given thing in C++ and what you want is to follow the coding practices of the team.

Well said.

One thing i have noticed is that many people trying to learn C++ (or any other language for that matter) don't even do the basic homework (eg. read a book) before asking questions. They expect everything to be spoon-fed and to "easily" understand it all. Even a little effort is too much. They simply lack the commitment and persistence to learn anything non-trivial.

So, your answer to somebody that found it difficult to get help from the c++ community is to first admit your are a misanthrope then direct the other guy to: go read some books and learn it for yourself!

Kind of proving the other persons point for them...

Read what I said:

1. stackoverflow is a bad "community" for any field.

2. I described how I would approach learning C++, based on my personality. I didn't "direct" anyone to do anything. Especially since I phrased it as a literal parenthetical.

For me I got the hints of something might go wrong with STL seeing more and more use, and then boost, various pointer types.. and it kept piling on. I'd say as soon as template metaprogramming became mainstream, in a language where it looked like a tumor, that was the end of it for me personally. It was not a language I knew anymore, nor cared about. C is a bit more verbose but concise enough to get around (if there's no abuse of pre-processor). With Rust, jury is still out there.

Yes. The explosion of meta programming in C++ was what killed my interest in that language. Too many layers of worthless abstraction that looked like they could have been written by an APL programmer having a seizure.

>there's no way you can do anything in the C++ codebase without a serious understanding of the language latest features

I don't mind using the latest features, there are some really nice things like iterators, compile time expressions and so on. I just don't want it to be hard to read or understand (like you said, using ALL the latest features).

So a good rule of thumb for me has been "if I give this to a newcomer, will he be able to infer what this is doing?". If yes, it's generally "safe" to use it.

> Basically, it seems they use all single features available.

And nobody is worried that the compiler implementations are not battle-tested and/or fully optimized yet? Because that alone would scare me off of using the newest features in production.

They're not using all the features for rational reasons in the first place! It's a rat race, plane and simple.

> But in my current company, there's no way you can do anything in the C++ codebase without a serious understanding of the language latest features.

I feel your anecdotal example is not fair as you're trying to pass off problems created by your team with it's ill-advised approach to adopting a programming language's latest features as problems with said programing language.

For instance, I feel you could make precisely the same case with a Java or Python project if the project's coding guidelines forced the adoption of all the new bells and whistles. But that wouldn't mean the languages have a problem.

Meanwhile, the golden rule of C++ continues to be favouring the principle of least surprise and picking a language version (often C++11, and not C++14/17/20) and a subset of features to be enforced at the project's coding guidelines, and build your project around those.

Frankly, your anecdotal example sounds more like resume-driven development claiming yet another victim than a programming language being too unwielding.

I agree I was a bit unfair, in the sense that it's not a problem specific to C++. It's extremely tempting for developers to use all tools and features available to them, and without very strong guidelines, you can be sure that it will happen.

That being said, C++ is an extremely complex language, so there's much more room for the code to become insanely complex than in more modern languages.

just wanted to say that I have seen this happen in my current company and so much so that certain portions of code basically look like boost headers. many folks dont want to touch that code so they end up duplicating functionality with slight change because that one minor change would take a life of itself.

in my previous company I have seen this happen (to a less extent) as a way of marking territory since such speghetti code sans detailed documentation basically means nobody else will touch it.