Yes. There are a very small handful of early adopters in the year 2025 for a feature ostensibly added in C++20.
So, like I said, modules don’t exist in practice and I’d be shocked if in 2030 modules were considered normal.
C++11 was pretty game changing. C++14 and C++17 only took a few years to reach widespread adoption.
It’s very safe to require C++17 today. C++20 was a little slower and because of the modules fuckup it’s a bit inconsistent. But it’s largely fine to use.
C++23 probably needs another year or two. But also C++20 and beyond haven’t added much that’s worth upgrading for.
Like I said, it is a matter of point of view, and yes such is the karma of ISO driven languages with multiple implementations, when one cares about cross platform code.
There are many folks that don't care though, for them it is "one platform, one compiler, language standard is whatever my compiler allows me to do, including extensions".
I am also quite bullish on the opinion that eventually, C++26 might be the last standard, not that WG21 will stop working on new ones, rather that is what many will care about when using C++ in a polyglot environment, as it is already the case in mobile OS platforms, the two major desktop platforms and distributed computing (CNCF project landscape).
> C++20 and beyond haven’t added much that’s worth upgrading for.
std::format is pretty nice (although not yet available on Ubuntu 24.04 LTS.
Lambda capture of parameter packs is actually huge!
And ... I think it still remains to be see what the outcome of modules will be.
One hopes (against hope) that the big payoff for modules will be in tool-ability of C++. IDE support for languages like C#, Java, typescript is vastly superior to C++ IDE tooling. Perhaps. Maybe. Modules will provide a path that will allow that to change. I don't think the benefits of modules have yet fully played out.
Ironically C++ had such tooling in the past but got lost, a bit like Roman technology as the Empire felt.
Visual Age for C++ v4.0 had a Smalltalk like experience with a database storage for the code, and Lucid Energize C++ already had something that people now know as LSP (Cadillac on their implementation), with incremental compilation and linking (at method/function level).
They failed commercially due to high prices and hardware requirements.
We have had C++ Builder for decades for GUI RAD development, Delphi/VB style, but due to how Borland went after the enterprise and various changes of hands, very few are aware that it exists and its capabilities.
C++ Builder with VCL was Java/.NET before these were even an idea looking for an implementation.
Problem now is that C++ has become a specialized tooling for high performance code, language runtimes, drivers and GPGPU, so you write 90% of the code in Java/C#/nodejs/..... and then reach out to native libraries, for various reasons.
Still, Clion, Visual Studio, C++ Builder, are quite good as far as development experience goes.
Could it be better? Most likely.