[schaefer]

I've been working professionally with c++ since 2001, and I'm currently a team lead.

The compensation packages we are able to offer to new hires means we're generally hiring from the middle of the talent pool, not the upper tier.

The complexity of c++ has long since outpaced the pace of fluency of the hiring pool. In my experience, the average c++ professional (that applies for our open job ads) knows c++14, and might not balk at an occasional c++17 feature.

It doesn't matter if the compilers support modules or not, because in practice, I won't be able to use modules in the workplace for ages.

--

Standard disclaimer - I'm not able to predict the crush of changes coming as generative AI for software development proliferates.

[alserio]

I haven't coded c++ professionally since a couple of standards ago. However, I believe that something like c++ modules can be picked up quickly even by "middle of the talent pool" devs, because it's a useful feature for them. What might hinder modules adoption, beside availability of the compilers, is the rest of the tooling ecosystem and the particular idiosyncrasies that most c++ projects have.

[bombcar]

In every major project I've been involved in (and it's not terribly many, to be fair) things keeping us on previous versions were almost always libraries or other support software, rarely if ever was it the devs.

[Longhanks]

Really? For me, it has been almost exclusively management not wanting to invest the manpower necessary for the adoption.

If the technology stack allows it, I assume most passionate developers would develop rather with newer than older toolchains.

[bombcar]

These might be two sides of the same coin - usually the reason there is a huge manpower requirement is because of the libraries and supporting tools.

Most developers want to use the newest and greatest, but are held back.

[stonemetal12]

Why not use them as soon as the compiler supports them? Your teammates will either ask you what it is (since you are the team lead), or look it up on cppreference.com.

[Maxatar]

I used to do this back when C++11 came out and ended up regretting it. When a feature just comes out, you can understand it possibly in isolation, but it's very hard to understand how that feature will fit in with other features, tools, libraries etc... and so you use it in a certain way according to how various blog posts and thought leaders say you should use it, and then after a year you end up realizing that no one could anticipate that the new feature has all kinds of footguns and certain features even end up being deprecated or superseded by yet another new feature.

When a new feature comes out, it's best to let it settle in a bit, maybe experiment using it on smaller side projects, but avoid diving into using it too early before it's really well understood.

For example I now cringe every time I see the curly bracket initialization of the form T{...} and how that was advocated as the one true way to initialize everything in C++, only for everyone to realize a year later that it has its own footguns (like with initialize lists) and with C++20 fixing almost all of the original problems that led to T{...}, the best practice nowadays is to go back to just using plain old T(...) and there's little to no reason to use T{...} anymore.

There was also Herb Sutter's Always Use Auto, which then was revised to Almost Always Use Auto, and now I think most developers take the sensible approach of use auto for redundant names like iterators, or unnamable types like lambda expressions, and avoid using it everywhere so as to turn your codebase into an opaque soup of inscrutable keywords.

[jampekka]

Also looking at C++ every day isn't a very fetching proposition.

[stefan_]

Yeah, I think grandparent is confusing "not knowing the language features" with "want nothing to do with the latest metaprogramming mess the cooks are serving". Job listings with C++ are a mess, you never know what level of insanity you are going to get (bonus shoutout for those that say "C/C++").

[Buttons840]

It's a chicken and egg problem.

You mention the average C++ programmer won't know the latest features, but if you did find an enthusiast who knew the latest features, you and the team probably wouldn't allow the use of those new features.

I can't imagine a more soul draining job than maintaining a corporate C++ codebase. Talk about doing the bare minimum.

[shrimp_emoji]

> I can't imagine a more soul draining job than maintaining a corporate C++ codebase.

To me, that's anything web-related in Java/C#/Go/JS.

[pif]

> I can't imagine a more soul draining job than maintaining a corporate C++ codebase.

Especially if most of the developers learnt Microsoft Visual C++ and believe that is proper C++!

[kevindamm]

re: changes coming from generative AI, it would need fluency in modules and other modern formulae. It would get that by being trained on modern conventions. So it's the same problem then, isn't it?