4 ms·

Not all organizations are in a position to make the switch or even want to. I personally like Rust and find it interesting, but that doesn't mean I would throw

by gp 4y ago

Not all organizations are in a position to make the switch or even want to. I personally like Rust and find it interesting, but that doesn't mean I would throw away my C++ codebase. I'm sure other people will be able to share reasons their organizations use C++

thesuperbigfrog 4y ago
>> I'm sure other people will be able to share reasons their organizations use C++ Rust is great and offers a great path forward, but it was not around 20+ years ago when $BIG_PROJECT was written. C++ was around, popular, and useful so $BIG_PROJECT was written in C++. $BIG_PROJECT made $BIG_COMPANY millions and is still in use today. $BIG_PROJECT engineers are looking into migrating parts of $BIG_PROJECT to Rust, but the work is still early and the $BIG_PROJECT's millions of lines of C++ won't be replaced overnight. Improved, more uniform tooling for C++ would simplify maintenance for $BIG_PROJECT and make it easier to move $BIG_PROJECT to newer C++ toolchains and even other C++ toolchain vendors. Maybe one day $BIG_PROJECT will migrate fully to Rust, or perhaps $BIG_PROJECT will be re-written from the ground up in Rust, but for now $BIG_PROJECT has to work.
chad1n 4y ago
I'm not a Rust apologetic, but even if the standard tooling committee appears, most big projects won't migrate to these tools, considering that they've been using some building scripts for 10-20 years and maintaining dependencies in hacky ways. These standard tools will mostly help new projects in C++ which can start from scratch and use vcpkg and whatever building tool will be selected (probably cmake or meson).
- bluGill 4y ago
  Projects will slowly migrate, as things are updated ' when a third party library release a version with this they will add support. When they need new features in their build system they will add them in this format, creating a weird hybrid until one day they turn the old stuff off.
- jcranmer 4y ago
  There are a few things to note here. First, the hacky build systems of old are increasingly unsustainable; I've seen quite a few projects migrate to things like cmake in part because not having that kind of build system just doesn't work anymore. (And you get people like Mozilla or Google who write their own build system just for their software, but the end result is the same--you've got some sort of modern-ish build system being integrated). Even at $WORK, some of our old build system stuff with confusing make rules and the like is being shifted to a (hopefully) cleaner cmake stuff, albeit far more slowly than I'd like. Second, it's worth noting that tooling improvements can motivate change. The ur-example here is the compilation database idea Clang introduced. From what I've seen, every build system that can support it (sorry, autotools) has added information to extract this useful tool. If you can come up with similarly useful build system summary information that is useful for tooling, you're likely to see relatively swift adoption of it. Third, C++ is already undergoing changes that will introduce build system breakages. Most notably and obviously, modules. Build systems need to adapt to support this, and if people are already making the switch to get new features, incorporating other useful tooling additions at the same time would see adoption.
  - cyber_kinetist 4y ago
    > I've seen quite a few projects migrate to things like cmake in part because not having that kind of build system just doesn't work anymore The problem is that CMake is also a cardboard castle built on numerous hacks that break every time a wind blows by. For library users it might be bearable, but for library writers it is absolute hell. And the consistent churn of new half-baked features and subpar documentation really doesn't help. (People talk about "modern" CMake like they do with "modern" C++, the churn is so similar...) The solution that I've found now is: I've built my own build system in Python that outputs a Ninja file, dead simple. Don't really have the urge to use CMake again (unless when I need to at $WORK)
    - germandiago 4y ago
      Let me play devil's advocate here. So you have your own Ninja file, great. How it deals with: - Use sanitizers - Compile for several operating systems, even some later you might need to port to. - Debug/relase/minsize builds - disable/enable warnings as errors - run test suites - use ccache - install stuff - consume external libraries - choose a nested common nested dependency for the same version for a lib, and, transitively, do it for all subdependencies (something I handle with Conan and/or Meson wraps) - dll import/export and symbol exposure - compile static/dynamic PIE/PIC libraries - custom compilation flags to distribute your lib god-does-not-know-where-yet. (for example distro maintainers) Now you might tell me you do not need much of that. And you would have a point. The problem is that when you start to mix and match projects If you have done all that, you did it ad-hoc. CMake at least can do it for all your projects. And CMake is really bad, IMHO, I much prefer Meson. For all the bad things CMake has, if you do even a 10th of this ad-hoc, you are already wasting time compared to using a battle-tested tool like CMake or Meson.

by gp 4y ago

thesuperbigfrog 4y ago

>> I'm sure other people will be able to share reasons their organizations use C++ Rust is great and offers a great path forward, but it was not around 20+ years ago when $BIG_PROJECT was written. C++ was around, popular, and useful so $BIG_PROJECT was written in C++. $BIG_PROJECT made $BIG_COMPANY millions and is still in use today. $BIG_PROJECT engineers are looking into migrating parts of $BIG_PROJECT to Rust, but the work is still early and the $BIG_PROJECT's millions of lines of C++ won't be replaced overnight. Improved, more uniform tooling for C++ would simplify maintenance for $BIG_PROJECT and make it easier to move $BIG_PROJECT to newer C++ toolchains and even other C++ toolchain vendors. Maybe one day $BIG_PROJECT will migrate fully to Rust, or perhaps $BIG_PROJECT will be re-written from the ground up in Rust, but for now $BIG_PROJECT has to work.

chad1n 4y ago

I'm not a Rust apologetic, but even if the standard tooling committee appears, most big projects won't migrate to these tools, considering that they've been using some building scripts for 10-20 years and maintaining dependencies in hacky ways. These standard tools will mostly help new projects in C++ which can start from scratch and use vcpkg and whatever building tool will be selected (probably cmake or meson).

bluGill 4y ago
Projects will slowly migrate, as things are updated ' when a third party library release a version with this they will add support. When they need new features in their build system they will add them in this format, creating a weird hybrid until one day they turn the old stuff off.
jcranmer 4y ago
There are a few things to note here. First, the hacky build systems of old are increasingly unsustainable; I've seen quite a few projects migrate to things like cmake in part because not having that kind of build system just doesn't work anymore. (And you get people like Mozilla or Google who write their own build system just for their software, but the end result is the same--you've got some sort of modern-ish build system being integrated). Even at $WORK, some of our old build system stuff with confusing make rules and the like is being shifted to a (hopefully) cleaner cmake stuff, albeit far more slowly than I'd like. Second, it's worth noting that tooling improvements can motivate change. The ur-example here is the compilation database idea Clang introduced. From what I've seen, every build system that can support it (sorry, autotools) has added information to extract this useful tool. If you can come up with similarly useful build system summary information that is useful for tooling, you're likely to see relatively swift adoption of it. Third, C++ is already undergoing changes that will introduce build system breakages. Most notably and obviously, modules. Build systems need to adapt to support this, and if people are already making the switch to get new features, incorporating other useful tooling additions at the same time would see adoption.
- cyber_kinetist 4y ago
  > I've seen quite a few projects migrate to things like cmake in part because not having that kind of build system just doesn't work anymore The problem is that CMake is also a cardboard castle built on numerous hacks that break every time a wind blows by. For library users it might be bearable, but for library writers it is absolute hell. And the consistent churn of new half-baked features and subpar documentation really doesn't help. (People talk about "modern" CMake like they do with "modern" C++, the churn is so similar...) The solution that I've found now is: I've built my own build system in Python that outputs a Ninja file, dead simple. Don't really have the urge to use CMake again (unless when I need to at $WORK)
  - germandiago 4y ago
    Let me play devil's advocate here. So you have your own Ninja file, great. How it deals with: - Use sanitizers - Compile for several operating systems, even some later you might need to port to. - Debug/relase/minsize builds - disable/enable warnings as errors - run test suites - use ccache - install stuff - consume external libraries - choose a nested common nested dependency for the same version for a lib, and, transitively, do it for all subdependencies (something I handle with Conan and/or Meson wraps) - dll import/export and symbol exposure - compile static/dynamic PIE/PIC libraries - custom compilation flags to distribute your lib god-does-not-know-where-yet. (for example distro maintainers) Now you might tell me you do not need much of that. And you would have a point. The problem is that when you start to mix and match projects If you have done all that, you did it ad-hoc. CMake at least can do it for all your projects. And CMake is really bad, IMHO, I much prefer Meson. For all the bad things CMake has, if you do even a 10th of this ad-hoc, you are already wasting time compared to using a battle-tested tool like CMake or Meson.