7 ms·

Biggest open question is whether the small changes to the module system in this standard will actually lead to more widespread adoption

forrestthewoods 7mo ago
No. Modules are a failed idea. Really really hard for me to see them becoming mainstream at this point.
- hrmtst93837 7mo ago
  [flagged]
- m-schuetz 7mo ago
  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.
  - evanmoran 7mo ago
    Exactly. C++ is still waiting for its "uv" moment, so until then modules aren't even close to solved.
    - lostdog 7mo ago
      And uv required some ground work, where the PEP process streamlined how you define a python project, and then uv could be built on top.
  - creato 7mo ago
    The idea is great in the same way the idea of a perpetual motion machine is great: I'd love to have a perpetual motion machine (or C++ modules), but it's just not realistic. IMO, the modules standard should have aimed to only support headers with no inline code (including no templates). That would be a severe limitation, but at least maybe it might have solved the problem posed by protobuf soup (AFAIK the original motivation for modules) and had a chance of being a real thing.
- Xraider72 7mo ago
  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.
  - StilesCrisis 7mo ago
    Much like contracts--yes, C++ needs something modules-like, but the actual design as standardized is not usable. Once big companies like Google started pulling out of the committee, they lost their connection to reality and now they're standardizing things that either can't be implemented or no one wants as specced.
    - pjmlp 7mo ago
      Usable enough for Office, and the initial proposal was done by Microsoft.
      - StilesCrisis 7mo ago
        I know Microsoft invested a lot into modules development and migrated a few small pieces of Office onto modules, but I'm not sure if they are actually using it extensively, and I'm also not sure if they're actually all that beneficial. Every time I hear about modules, it's stories about a year of migration work for a single-digit build-time improvement.
  - forrestthewoods 7mo ago
    I emphatically agree. C++ needs a standard build system that doesn’t suck ass. Most people would agree it needs a package manager although I think that is actually debatable. Neither of those things require modules as currently defined.
    - germandiago 7mo ago
      That is not even half realistic. Are you going to port all that code out there (autotools, cmake, scons,meson, bazel, waf...) to a "true" build system? Only the idea is crazy. What Conan does is much more sensible: give s layer independent of the build system (and a way to consume packages and if you want some predefined "profiles" such as debug, etc), leave it half-open for extensions and let existing tools talk with that communication protocol. That is much more realistic and you have way more chances of having a full ecosystem to consume. Also, noone needs to port full build system or move from oerfectly working build systems.
- AyanamiKaine 7mo ago
  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.
  - devnullbrain 7mo ago
    I'm not the PC but I think you miss most of the pain points due to: 'personal' projects. There's not a compatible format between different compilers, or even different versions of the same compiler, or even the same versions of the same compiler with different flags. This seems immediately to create too many permutations of builds for them to be distributable artifacts as we'd use them in other languages. More like a glorified object file cache. So what problem does it even solve?
    - nickelpro 7mo ago
      BMIs are not considered distributable artifacts and were never designed to be. Same as PCHs and clang-modules which preceded them. Redistribution of interface artifacts was not a design goal of C++ modules, same as redistribution of CPython byte code is not a design goal for Python's module system. Modules solve the problems of text substitution (headers) as interface description. It's why we call the importable module units "interface units". The goals were to fix all the problems with headers (macro leakage, uncontrolled export semantics, Static Initialization Order Fiasco, etc) and improve build performance. They succeeded at this rather wonderfully as a design. Implementation proved more difficult but we're almost there.
  - forrestthewoods 7mo ago
    Because as a percentage of global C++ builds they’re used in probably 0.0001% of builds with no line of sight to that improving. They have effectively zero use outside of hobby projects. I don’t know that any open source C++ library I have ever interacted with even pretends that modules exist.
zarzavat 7mo ago
The best thing the C++ WG could do is to spend an entire release cycle working on modules and packaging. It's nice to have new features, but what is really killing C++ is Cargo. I don't think a new generation of developers are going to be inspired to learn a language where you can't simply `cargo add` whatever you need and instead have to go through hell to use a dependency.
- luka598 7mo ago
  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.
  - mgaunard 7mo ago
    It's fundamentally different; Rust entirely rejects the notion of a stable ABI, and simply builds everything from source. C and C++ are usually stuck in that antiquated thinking that you should build a module, package it into some libraries, install/export the library binaries and associated assets, then import those in other projects. That makes everything slow, inefficient, and widely dangerous. There are of course good ways of building C++, but those are the exception rather than the standard.
    - stackghost 7mo ago
      >There are of course good ways of building C++, but those are the exception rather than the standard. What are the good ways?
      - lstodd 7mo ago
        "Do not do it" looks like the winning one nowadays.
      - mgaunard 7mo ago
        Build everything from source within a single unified workspace, cache whatever artifacts were already built with content-addressable storage so that you don't need to build them again. You should also avoid libraries, as they reduce granularity and needlessly complexify the logic. I'd also argue you shouldn't have any kind of declaration of dependencies and simply deduce them transparently based on what the code includes, with some logic to map header to implementation files.
jjmarr 7mo ago
No, because most major compilers don't support header units, much less standard library header units from C++26. What'll spur adoption is cmake adopting Clang's two-step compilation model that increases performance. At that point every project will migrate overnight for the huge build time impact since it'll avoid redundant preprocessing. Right now, the loss of parallelism ruins adoption too much.
dheera 7mo ago
I frankly wish we'd stop developing C++. It's so hard to keep track of all the new unnecessary toys they're adding to it. I thought I knew C++ until I read some recent C++ code. That's how bad it is. Meanwhile C++ build system is an abomination. Header files should be unnecessary.
- ranger_danger 7mo ago
  You don't have to keep up with or use any of the new features. I still pay my bills writing C++98 and have no desire to use a higher version.

forrestthewoods 7mo ago

No. Modules are a failed idea. Really really hard for me to see them becoming mainstream at this point.

hrmtst93837 7mo ago
[flagged]
m-schuetz 7mo ago
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.
- evanmoran 7mo ago
  Exactly. C++ is still waiting for its "uv" moment, so until then modules aren't even close to solved.
  - lostdog 7mo ago
    And uv required some ground work, where the PEP process streamlined how you define a python project, and then uv could be built on top.
- creato 7mo ago
  The idea is great in the same way the idea of a perpetual motion machine is great: I'd love to have a perpetual motion machine (or C++ modules), but it's just not realistic. IMO, the modules standard should have aimed to only support headers with no inline code (including no templates). That would be a severe limitation, but at least maybe it might have solved the problem posed by protobuf soup (AFAIK the original motivation for modules) and had a chance of being a real thing.
Xraider72 7mo ago
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.
- StilesCrisis 7mo ago
  Much like contracts--yes, C++ needs something modules-like, but the actual design as standardized is not usable. Once big companies like Google started pulling out of the committee, they lost their connection to reality and now they're standardizing things that either can't be implemented or no one wants as specced.
  - pjmlp 7mo ago
    Usable enough for Office, and the initial proposal was done by Microsoft.
    - StilesCrisis 7mo ago
      I know Microsoft invested a lot into modules development and migrated a few small pieces of Office onto modules, but I'm not sure if they are actually using it extensively, and I'm also not sure if they're actually all that beneficial. Every time I hear about modules, it's stories about a year of migration work for a single-digit build-time improvement.
- forrestthewoods 7mo ago
  I emphatically agree. C++ needs a standard build system that doesn’t suck ass. Most people would agree it needs a package manager although I think that is actually debatable. Neither of those things require modules as currently defined.
  - germandiago 7mo ago
    That is not even half realistic. Are you going to port all that code out there (autotools, cmake, scons,meson, bazel, waf...) to a "true" build system? Only the idea is crazy. What Conan does is much more sensible: give s layer independent of the build system (and a way to consume packages and if you want some predefined "profiles" such as debug, etc), leave it half-open for extensions and let existing tools talk with that communication protocol. That is much more realistic and you have way more chances of having a full ecosystem to consume. Also, noone needs to port full build system or move from oerfectly working build systems.
AyanamiKaine 7mo ago
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.
- devnullbrain 7mo ago
  I'm not the PC but I think you miss most of the pain points due to: 'personal' projects. There's not a compatible format between different compilers, or even different versions of the same compiler, or even the same versions of the same compiler with different flags. This seems immediately to create too many permutations of builds for them to be distributable artifacts as we'd use them in other languages. More like a glorified object file cache. So what problem does it even solve?
  - nickelpro 7mo ago
    BMIs are not considered distributable artifacts and were never designed to be. Same as PCHs and clang-modules which preceded them. Redistribution of interface artifacts was not a design goal of C++ modules, same as redistribution of CPython byte code is not a design goal for Python's module system. Modules solve the problems of text substitution (headers) as interface description. It's why we call the importable module units "interface units". The goals were to fix all the problems with headers (macro leakage, uncontrolled export semantics, Static Initialization Order Fiasco, etc) and improve build performance. They succeeded at this rather wonderfully as a design. Implementation proved more difficult but we're almost there.
- forrestthewoods 7mo ago
  Because as a percentage of global C++ builds they’re used in probably 0.0001% of builds with no line of sight to that improving. They have effectively zero use outside of hobby projects. I don’t know that any open source C++ library I have ever interacted with even pretends that modules exist.

zarzavat 7mo ago

The best thing the C++ WG could do is to spend an entire release cycle working on modules and packaging. It's nice to have new features, but what is really killing C++ is Cargo. I don't think a new generation of developers are going to be inspired to learn a language where you can't simply `cargo add` whatever you need and instead have to go through hell to use a dependency.

luka598 7mo ago
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.
- mgaunard 7mo ago
  It's fundamentally different; Rust entirely rejects the notion of a stable ABI, and simply builds everything from source. C and C++ are usually stuck in that antiquated thinking that you should build a module, package it into some libraries, install/export the library binaries and associated assets, then import those in other projects. That makes everything slow, inefficient, and widely dangerous. There are of course good ways of building C++, but those are the exception rather than the standard.
  - stackghost 7mo ago
    >There are of course good ways of building C++, but those are the exception rather than the standard. What are the good ways?
    - lstodd 7mo ago
      "Do not do it" looks like the winning one nowadays.
    - mgaunard 7mo ago
      Build everything from source within a single unified workspace, cache whatever artifacts were already built with content-addressable storage so that you don't need to build them again. You should also avoid libraries, as they reduce granularity and needlessly complexify the logic. I'd also argue you shouldn't have any kind of declaration of dependencies and simply deduce them transparently based on what the code includes, with some logic to map header to implementation files.

jjmarr 7mo ago

No, because most major compilers don't support header units, much less standard library header units from C++26. What'll spur adoption is cmake adopting Clang's two-step compilation model that increases performance. At that point every project will migrate overnight for the huge build time impact since it'll avoid redundant preprocessing. Right now, the loss of parallelism ruins adoption too much.

dheera 7mo ago

I frankly wish we'd stop developing C++. It's so hard to keep track of all the new unnecessary toys they're adding to it. I thought I knew C++ until I read some recent C++ code. That's how bad it is. Meanwhile C++ build system is an abomination. Header files should be unnecessary.

ranger_danger 7mo ago
You don't have to keep up with or use any of the new features. I still pay my bills writing C++98 and have no desire to use a higher version.