4 ms·

> Modules promise to significantly change the structure of C++ codebases and possibly signal headers’ ultimate demise (but probably not in my lifetime). It also

> Modules promise to significantly change the structure of C++ codebases and possibly signal headers’ ultimate demise (but probably not in my lifetime). It also opens the door to potentially have a unified build system and package manager, similar to Rust’s Cargo package manager; though I imaging standardising a unified build system would be one bloody battle. I wonder how many folks, like me, have stopped using C++ because it's too much effort to manage the build system and the overhead of headers adds too much to compile time? An enormous draw for alternatives, like Rust, Zig, Nim et al is that they simply don't have these problems.

tempest_ 5y ago
Honestly the modern build system is my favourite feature of rust. No messing with autoconfs, and make files that spit out some random gcc error I have to debug. To be fair however I am also not too interested in c++ and its 30 years of foot guns either so take it for what its worth.
- ridiculous_fish 5y ago
  How does Rust handle problems like "call this function if it exists?" Is there support in build scripts?
  - comex 5y ago
    It doesn't. Indeed, when it comes to libc and other system libraries (or really most C libraries in general), the Rust ecosystem relies on hardcoding the ABI of every supported platform. It's theoretically possible to use bindgen (which parses C headers) as a build step, but this is rarely done.
- saagarjha 5y ago
  In my experience Rust’s ability to rid itself from autoconf comes not because of any inherent benefits but because Rust code typically does not support systems where autoconf would really be required. For the mostly sane platform differences, the popular ones are probably hardcoded in some dependency crate with “-std” in its name so you don’t have to see it, unless of course it turns out to not support your less common platform or the check is broken, in which case you lob a GitHub issue at them and they deal with it.
  - ridiculous_fish 5y ago
    Rust does support a surprisingly deep set of platforms, but it achieves this by baking platform-specific knowledge into Rust itself. See for example how it finds errno, it's just a big list of special cases. It is pleasant to not need the configure scripts, but a downside is that no new platform can participate without first patching Rust. https://doc.rust-lang.org/src/std/sys/unix/os.rs.html#38 https://doc.rust-lang.org/src/std/sys/unix/os.rs.html#38
    - steveklabnik 5y ago
      (Into the standard library, not into Rust itself. Anyone can write this, you don't need to patch Rust first just to call some functions.)
    - nicoburns 5y ago
      I believe you can write your own completely separate standard library if you want to (much like each platform typically has it's own libc). It's just that it's easier to manage the first-party supported platforms as one codebase.
  - saghm 5y ago
    I think there's an argument to be made that some developers might be willing to sacrifice portability to some lesser-used platforms in order to make the ecosystem a bit cleaner for the platforms it does support. This is definitely a tradeoff though, so it make sense and is good that different ecosystems make difference choices here, as it allows people to choose whichever suits them best.
  - pjmlp 5y ago
    Yes, cargo is perfect if you are willing to always compile from source, everything is Rust and one is willing to deal with everything else themselves in build.rs scripts. Google and Microsoft aren't using cargo on their projects, rather had to come up with their own build tool.
    - ithkuil 5y ago
- pjmlp 5y ago
  Now try to integrate it on mixed codebase like Android or Fuchsia.
skywal_l 5y ago
Zig doesn't have a package manager like rust does. They are competing "non-official" implementations that are not compatible with each other. Zig is in the same state as C++ right now with vcpkg, build 2, conan, etc... But there is an effort[0] from the "core team" (meaning Andrew Kelley the author or Zig) to push for an "official solution". Maybe, the same way Zig makes cross-compiling C/C++ easier we might see a Zig package manager making C/C++ packaging easier too. [0] https://github.com/ziglang/zig/issues/943 https://github.com/ziglang/zig/issues/943
- AndyKelley 5y ago
  To provide some more context, here is a snippet from the latest release notes[0]: > Having a package manager built into the Zig compiler is a long-anticipated feature. Zig 0.8.0 does not have this feature. > If the package manager works well, people will use it, which means building Zig projects will involve compiling more lines of Zig code, which means the Zig compiler must get faster, better at incremental compilation, and better at resource management. > Therefore, the package manager depends on finishing the Self-Hosted Compiler, since it is planned to have these improved performance characteristics, while the Bootstrap Compiler is not planned to have them. I can't help but mention, I am incredibly excited about how well the self-hosted compiler is coming along. Progress is swift, and all the ambitious design decisions (fully incremental compilation[1], extremely fast debug builds[2], low memory usage, multi-threaded) are intact. I anticipate it to make quite a splash once it becomes generally usable. I don't expect the package manager to take nearly as long to develop. [0]: https://ziglang.org/download/0.8.0/release-notes.html#Package-Manager-Status https://ziglang.org/download/0.8.0/release-notes.html#Packag... [1]: https://vimeo.com/491488902 https://vimeo.com/491488902 [2]: https://twitter.com/andy_kelley/status/1416485475125141504 https://twitter.com/andy_kelley/status/1416485475125141504
  - makapuf 5y ago
    I long for the times where there were less package managers, not more. Maybe two at most (one for distros and one for developers maybe) but isn't it time for some kind of standardisation? One per language is not justified.
pjmlp 5y ago
Neither does C++ when using IDE build tools. It is just many anti-IDE folks never get to adopt them.
- gmueckl 5y ago
  The only problem woth this approach is that C++ IDEs are silos of their own: Visual Studio on Windows, XCode on MacOS, whatever the heck you want to use on Linux... you quickly end up maintaining a lot of project files if you have a cross platform project. Damned if you do, damned if you don't...
  - pjmlp 5y ago
    Not every project needs to be cross platform.
    - gmueckl 5y ago
      Correct. And e.g. Visual Studio is kind of nice if you only need to develop for Windows. It's just that in my experience the pain with build systems invariably starts to increase when you actually have to go cross platform.
jlokier 5y ago
> stopped using C++ because [...] and the overhead of headers adds too much to compile time? > An enormous draw for alternatives, like Rust, Zig, Nim et al is that they simply don't have these problems. I'm using Nim full time at the moment in a large project. Like Rust, it certainly does have the compile time problem due to parsing lots of files! Every compile, Nim processes every source file in the program, including libraries, and this can take minutes. Unlike C++ where each source file can be compiled in parallel, and after a small change most files usually don't need to be recompiled, Nim's scan of the whole program's source files is single-threaded, so it's the slowest part of the build. Nim compiles to C, and the C compilation and linking steps are relatively fast because the C compilations are run in parallel and cached.

tempest_ 5y ago

Honestly the modern build system is my favourite feature of rust. No messing with autoconfs, and make files that spit out some random gcc error I have to debug. To be fair however I am also not too interested in c++ and its 30 years of foot guns either so take it for what its worth.

ridiculous_fish 5y ago
How does Rust handle problems like "call this function if it exists?" Is there support in build scripts?
- comex 5y ago
  It doesn't. Indeed, when it comes to libc and other system libraries (or really most C libraries in general), the Rust ecosystem relies on hardcoding the ABI of every supported platform. It's theoretically possible to use bindgen (which parses C headers) as a build step, but this is rarely done.
saagarjha 5y ago
In my experience Rust’s ability to rid itself from autoconf comes not because of any inherent benefits but because Rust code typically does not support systems where autoconf would really be required. For the mostly sane platform differences, the popular ones are probably hardcoded in some dependency crate with “-std” in its name so you don’t have to see it, unless of course it turns out to not support your less common platform or the check is broken, in which case you lob a GitHub issue at them and they deal with it.
- ridiculous_fish 5y ago
  Rust does support a surprisingly deep set of platforms, but it achieves this by baking platform-specific knowledge into Rust itself. See for example how it finds errno, it's just a big list of special cases. It is pleasant to not need the configure scripts, but a downside is that no new platform can participate without first patching Rust. https://doc.rust-lang.org/src/std/sys/unix/os.rs.html#38 https://doc.rust-lang.org/src/std/sys/unix/os.rs.html#38
  - steveklabnik 5y ago
    (Into the standard library, not into Rust itself. Anyone can write this, you don't need to patch Rust first just to call some functions.)
  - nicoburns 5y ago
    I believe you can write your own completely separate standard library if you want to (much like each platform typically has it's own libc). It's just that it's easier to manage the first-party supported platforms as one codebase.
- saghm 5y ago
  I think there's an argument to be made that some developers might be willing to sacrifice portability to some lesser-used platforms in order to make the ecosystem a bit cleaner for the platforms it does support. This is definitely a tradeoff though, so it make sense and is good that different ecosystems make difference choices here, as it allows people to choose whichever suits them best.
- pjmlp 5y ago
  Yes, cargo is perfect if you are willing to always compile from source, everything is Rust and one is willing to deal with everything else themselves in build.rs scripts. Google and Microsoft aren't using cargo on their projects, rather had to come up with their own build tool.
  - ithkuil 5y ago
pjmlp 5y ago
Now try to integrate it on mixed codebase like Android or Fuchsia.

skywal_l 5y ago

Zig doesn't have a package manager like rust does. They are competing "non-official" implementations that are not compatible with each other. Zig is in the same state as C++ right now with vcpkg, build 2, conan, etc... But there is an effort[0] from the "core team" (meaning Andrew Kelley the author or Zig) to push for an "official solution". Maybe, the same way Zig makes cross-compiling C/C++ easier we might see a Zig package manager making C/C++ packaging easier too. [0] https://github.com/ziglang/zig/issues/943 https://github.com/ziglang/zig/issues/943

AndyKelley 5y ago
To provide some more context, here is a snippet from the latest release notes[0]: > Having a package manager built into the Zig compiler is a long-anticipated feature. Zig 0.8.0 does not have this feature. > If the package manager works well, people will use it, which means building Zig projects will involve compiling more lines of Zig code, which means the Zig compiler must get faster, better at incremental compilation, and better at resource management. > Therefore, the package manager depends on finishing the Self-Hosted Compiler, since it is planned to have these improved performance characteristics, while the Bootstrap Compiler is not planned to have them. I can't help but mention, I am incredibly excited about how well the self-hosted compiler is coming along. Progress is swift, and all the ambitious design decisions (fully incremental compilation[1], extremely fast debug builds[2], low memory usage, multi-threaded) are intact. I anticipate it to make quite a splash once it becomes generally usable. I don't expect the package manager to take nearly as long to develop. [0]: https://ziglang.org/download/0.8.0/release-notes.html#Package-Manager-Status https://ziglang.org/download/0.8.0/release-notes.html#Packag... [1]: https://vimeo.com/491488902 https://vimeo.com/491488902 [2]: https://twitter.com/andy_kelley/status/1416485475125141504 https://twitter.com/andy_kelley/status/1416485475125141504
- makapuf 5y ago
  I long for the times where there were less package managers, not more. Maybe two at most (one for distros and one for developers maybe) but isn't it time for some kind of standardisation? One per language is not justified.

pjmlp 5y ago

Neither does C++ when using IDE build tools. It is just many anti-IDE folks never get to adopt them.

gmueckl 5y ago
The only problem woth this approach is that C++ IDEs are silos of their own: Visual Studio on Windows, XCode on MacOS, whatever the heck you want to use on Linux... you quickly end up maintaining a lot of project files if you have a cross platform project. Damned if you do, damned if you don't...
- pjmlp 5y ago
  Not every project needs to be cross platform.
  - gmueckl 5y ago
    Correct. And e.g. Visual Studio is kind of nice if you only need to develop for Windows. It's just that in my experience the pain with build systems invariably starts to increase when you actually have to go cross platform.

jlokier 5y ago

> stopped using C++ because [...] and the overhead of headers adds too much to compile time? > An enormous draw for alternatives, like Rust, Zig, Nim et al is that they simply don't have these problems. I'm using Nim full time at the moment in a large project. Like Rust, it certainly does have the compile time problem due to parsing lots of files! Every compile, Nim processes every source file in the program, including libraries, and this can take minutes. Unlike C++ where each source file can be compiled in parallel, and after a small change most files usually don't need to be recompiled, Nim's scan of the whole program's source files is single-threaded, so it's the slowest part of the build. Nim compiles to C, and the C compilation and linking steps are relatively fast because the C compilations are run in parallel and cached.