5 ms·

I remember this article, thanks for the memory :) I would disagree that not much have changed though I agree that I would prefer if we were positioned even bet

I remember this article, thanks for the memory :) I would disagree that not much have changed though I agree that I would prefer if we were positioned even better. For example the dominant use of CMake has made using other projects as a dependency easier. there are more package managers than there used to be.

erwincoumans 4y ago
Agreed, I'm glad cmake became more widely used. For Python I prefer using setuptools without further dependency to cmake, to make it easier for installation. Also, I was at Google, which used blaze/bazel mostly. Curious how the C++ world looks like in 10 years from now, or maybe we moved to Rust?
- mathstuf 4y ago
  [ FD: CMake developer, but this is just my personal opinion. ] I find Bazel, Buck, and other similar tools from other FAANG-like companies to mostly target monorepos because they expect to control everything from the toolchain up. Dependencies get vendored and use of things from outside the repo is difficult and actively discouraged. It solves its problems, but that's not the realm I work in (or, frankly, care a lot about as these projects have enough zeroes backing their development anyways). IME, these kinds of things doesn't really happen in FOSS codebases organically. I also don't see Rust taking over much of the C or C++ world in any kind of replacement way. Rust will become more popular and as projects die over time, they'll just be more likely to have been in C or C++ than Rust. I have no doubts that Rust will have this time in its lifecycle too. But the languages will never truly die. The best thing that could happen to C and C++ ecosystems is for projects to stop caring about and relying on build flags, `-D`-directed configuration, and flag soup-based dependency management (`pkg-config`). An in-language way to do conditional compilation based on concrete queries (e.g., ask the compiler about itself, the target, some dependency info) would do wonders here to replace the inscrutable black box that is the preprocessor and its magic names. It would to enable projects to just say "I use X" and have that mean something other than work for build systems to discover, extract, and then communicate to the compiler about what that actually means through each one's local command line flag dialect. But I don't expect that to ever see the light of day before C++32 and C40 nevermind being something one can rely on until after 2050 or so.
  - j_not_j 4y ago
    > An in-language way to do conditional compilation... Nim has some of this. But of course, it is not C.

erwincoumans 4y ago

Agreed, I'm glad cmake became more widely used. For Python I prefer using setuptools without further dependency to cmake, to make it easier for installation. Also, I was at Google, which used blaze/bazel mostly. Curious how the C++ world looks like in 10 years from now, or maybe we moved to Rust?

mathstuf 4y ago
[ FD: CMake developer, but this is just my personal opinion. ] I find Bazel, Buck, and other similar tools from other FAANG-like companies to mostly target monorepos because they expect to control everything from the toolchain up. Dependencies get vendored and use of things from outside the repo is difficult and actively discouraged. It solves its problems, but that's not the realm I work in (or, frankly, care a lot about as these projects have enough zeroes backing their development anyways). IME, these kinds of things doesn't really happen in FOSS codebases organically. I also don't see Rust taking over much of the C or C++ world in any kind of replacement way. Rust will become more popular and as projects die over time, they'll just be more likely to have been in C or C++ than Rust. I have no doubts that Rust will have this time in its lifecycle too. But the languages will never truly die. The best thing that could happen to C and C++ ecosystems is for projects to stop caring about and relying on build flags, `-D`-directed configuration, and flag soup-based dependency management (`pkg-config`). An in-language way to do conditional compilation based on concrete queries (e.g., ask the compiler about itself, the target, some dependency info) would do wonders here to replace the inscrutable black box that is the preprocessor and its magic names. It would to enable projects to just say "I use X" and have that mean something other than work for build systems to discover, extract, and then communicate to the compiler about what that actually means through each one's local command line flag dialect. But I don't expect that to ever see the light of day before C++32 and C40 nevermind being something one can rely on until after 2050 or so.
- j_not_j 4y ago
  > An in-language way to do conditional compilation... Nim has some of this. But of course, it is not C.