The idea is great, the execution is terrible. In JS, modules were instantly popular because they were easy to use, added a lot of benefit, and support in browsers and the ecoysystem was fairly good after a couple of years. In C++, support is still bad, 6 years after they were introduced.

No idea if modules themselves are failed or no, but if c++ wants to keep fighting for developer mindshare, it must make something resembling modules work and figure out package management.

yes you have CPM, vcpkg and conan, but those are not really standard and there is friction involved in getting it work.

"Failed idea" gives modules too much credit. Outside old codebases, almost no one outside C++ diehards have the patience for the build and tooling circuss they create, and if you need fast iteration plus sane integration with existing deps, modules are like trading your shoes for roller skates in a gravel lot. Adopting them now feels like volunteering to do tax forms in assembbly.

Can you explain why you think modules are a failed idea? Because not that many use them right now?

Personally I use them in new projects using XMake and it just works.

Agreed, arcane cmake configs and or bash build scripts are genuinely off-putting. Also cpp "equivalents" of cargo which afaik are conan and vcpkg are not default and required much more configuring in comparison with cargo. Atleast this was my experience few years ago.

I didn’t think header only was that bad - now we have a nightmare of incompatible standards and compilers.

In my experience, no one does build systems right; Cargo included.

The standard was initially meant to standardize existing practice. There is no good existing practice. Very large institutions depending heavily on C++ systematically fail to manage the build properly despite large amounts of third party licenses and dedicated build teams.

With AI, how you build and integrate together fragmented code bases is even more important, but someone has yet to design a real industry-wide solution.

I’m still surprised how people ignore Meson. Please test it :)

https://mesonbuild.com/

And Mesons awesome dependency handling:

https://mesonbuild.com/Dependencies.html

https://mesonbuild.com/Using-the-WrapDB.html#using-the-wrapd...

https://nibblestew.blogspot.com/2026/02/c-and-c-dependencies...

I suffered with Java from Any, Maven and Gradle (the oldest is the the best). After reading about GNU Autotools I was wondering why the C/C++ folks still suffer? Right at that time Meson appeared and I skipped the suffering.

    * No XML
    * Simple to read and understand
    * Simple to manage dependencies
    * Simple to use options

Feel free to extend WrapDB.

To me, the most important feature of Cargo isn't even the dependency management but that I don't ever need to tell it which files to compile or where to find them. The fact that it knows to look for lib.rs or main.rs in src and then recursively find all my other modules without me needing to specify targets or anything like that is a killer feature on its own IMO. Over the past couple of years I've tried to clone and build a number of dotnet packages for various things, but for an ecosystem that's supposedly cross-platform, almost none of them seem to just work by default when I run `dotnet build` and instead require at least some fixes in the various project files. I don't think I've ever had an issue with a Rust project, and it's hard not to feel like a big part of that is because there's not really much configuration to be done. The list of dependencies is just about the only thing in there that effects the default build; if there's any other configuration other than that and the basic metadata like the name, the repo link, the license, etc., it almost always will end up being specifically for alternate builds (like extra options for release builds, alternate features that can be compiled in, etc.).

Support in GCC isn't what limits my usage of latest C++ at work.

Right, I think the tension here is that we would like contracts to exist in the language, but the current design isn't what it needs to be, and once it's standardized, it's extremely hard to fix.

The people who did contracts are aware of ada/spark and some have experience using it. Only time will tell if it works in c++ but they at least did all they could to give it a chance.

Note that this is not the end of contrats. This is a minimun viable start that they intend to add to but the missing parts are more complex.

C++ is the last language I'd add to any list of languages used for correct-by-design - it's underspecified in terms of semantics with huge areas of UB and IB. Given its vast complexity - at every level from the pre-processor to template meta-programming and concepts, I simply can't imagine any formal denotational definition of the language ever being developed. And without a formal semantics for the language, you cannot even start to think about proof of correctness.

The devil is in the details, because standardization work is all about details.

From my outside vantage point, there seems to be a few different camps about what is desired for contracts to even be. The conflict between those groups is why this feature has been contentious for... a decade now?

Some of the pushback against this form of contracts is from people who desire contracts, but don't think that this design is the one that they want.

But why? You can do everything contracts do in your own code, yes? Why make it a language feature?

This is interesting! People ignoring this, I think, is also interesting on its own. I respect if other people disagree, but that's my 2c. I think our overton windows may not agree here, but I think this is part of the value of discussions with other humans.

Are you a moderator? The directive tone of this post is as if from an authority figure, but, but I do not believe you are one.

I do not believe there is anything about a religious or ideological background here. Could you please clarify?

I also believe it is your post that could be more accurately described as trampling curiosity; I believe there is a role reversal, in that I think your comment is a better description for trampling curiosity than the post your are responding. I'm not trying to be snarky - I'm curious how you came to those conclusions.