Hacker News Reader

Comment by Night_Thastus | Hacker News Reader

As someone who works in C++, the build systems are definitely the worst part. QMake is abandoned. Cmake is the de-facto option and is an ancient horrible mess that feels like a miracle if it works at all. What's left?

Options that are barely supported, severely limited in features, are only reasonable for tiny side projects, etc.

View on HN

Aside from tooling (which is much better in Rust), C++ just isn't a very expressive language and has a high impedance with cognition. I've worked in C++ for well over a decade, and now that I've used Rust for a couple years, I just don't ever want to go back. It solves too many pain points of C++ to ignore.

> C++ just isn't a very expressive language

Compared to what? Modern C++ is by far the most expressive systems language. That is its primary selling point. It isn’t pretty but it is uniquely powerful. One of the reasons C++ isn’t disappearing any time soon is that it elegantly and efficiently handles some software design problems that Rust struggles with. Rust and C++ are optimized for different types of software.

As is implied, the type of software someone is writing has a large impact on whether or not they need the expressiveness of C++.

Can you elaborate on how Rust and C++ differ in the kinds of software they’re optimized for? And what makes C++ more elegant for purpose?

> Modern C++ is by far the most expressive systems language.

If you want to iterate over a range of integers, you need to manually explain to the computer how to do it. In 2023. Also, you need to Write Everything Twice because of the ancient header system.

No you don't. That is what ranges and modules are for.

Ranges: kind of, there is the very awkwardly named std::ranges::iota_view, but it doesn't support random access and who knows if the compiler can optimize iteration over it into a simple loop.

Modules are not supported by most compilers (in g++ you have to enable them as an experimental feature with -fmodules-ts, and if you want to import the standard library as modules, you need to pre-compile them into your project directory with some arcane commands).

Ranges: they are there, naming is a matter of taste.

Modules: GCC and clang will eventually get there, I am already enjoying them on VC++

    #define RANGE(type, name, last) type name = 0, last__ = (last); name != last__; name++

    for (RANGE(i32, i, foo->count))
        ...

That solves the problem even in C. But why care much, typing a few plain loops isn't among the hard problems to solve.

Compared to Rust.

Once you you've worked enough with proper enums and matches, that's the first thing you'll be lacking in C++ (and no, std::variant is a horrible mess without proper syntax support and doesn't even get close).

If anything, C++ is too expressive...

There is a difference between what you can do at all, and what you can do without hard thinking. C++ makes a lot of things possible, but fewer things easily possible. I program mostly in C++ and I don't hate it, FWIW...

Agreed, but I would probably still be programming in C++ if the tooling weren’t so bad, irrespective of the expressiveness. That said, I’m glad Rust is expressive, but more glad that it picked a coherent set of language features—it feels much less cobbled together than C++ if only for the benefit of hindsight.

Not very expressive? Are we talking about ARM C++ here?

C++ has lots of problems, lack of expressiveness isn't one of them.

> C++ just isn't a very expressive language and has a high impedance with cognition.

I feel that you are the very first person ever making such a statement. Can you provide what's your single best example showing C++'s inexpressiveness and "high impedance with cognition"?

Sum types. And/or proper error handling (also related to sum types).

I've had great experience with migrating C/C++ projects at work to use Bazel, at least in the sense that a couple of hours' work yields me a fast, correct, reproducible build and has usually sped up incremental build times by orders of magnitude.

But in a corporate environment where repositories are often authenticated, the fact that dependency fetch issues are reported as Java exceptions (having the wrong password in your netrc file shows up as "IOException occurred during fetch of ... Code 401") is a deal breaker for a C/C++ development staff unfamiliar with Java.

They happily take their ten minute incremental builds and "it works on my machine" issues in return for a build process they can understand, and as much as I want them to be wrong (I use Bazel all the time at home), I can't blame them for wanting tooling they understand.

Yeah, Bazel’s ergonomics can leave a lot to be desired, but to me the results are worth those issues. In general, changes to Bazel rules are much less common compared to code changes, so at least it’s only a small subset of time where you might see such issues.

For this sort of thing, what I tend to do is write doctor scripts that check this kind of stuff "out of band". Can be tricky, but like "have credential stored in a file, then have an out of band script that checks that the credentials can reach a server" can save a lot of headaches. "Did you run the doctor script?"

Bazel is supported by Google and is quite good. I’d certainly take it over CMake.

Interesting. My friend, who works at well known gaming company you've probably heard of, recently spent several months of his life fighting back against a group of people that came in from an acquisition that were trying to convert the company's well-working CMake system over to Bazel. He described it in pretty poor terms and described how it constantly caused the build system to fail. He eventually succeeded in convincing management to keep the CMake system rather than converting it to Bazel at the objection of the more senior devs from the acquisition.

It’s a somewhat steep learning curve, but in my experience once you have your Bazel rules set up properly, it’s incredibly powerful, enabling lots of time savings from caching, as well as helping enforce reproducible outputs.

I feel like Bazel is much more convincing _after it's working_, cuz you really do get much faster builds. But the work has to be done, and there's a lot of unlearning to do.

If your project doesn't take long to compile or test anyways.... I can see getting annoyed.

> I feel like Bazel is much more convincing _after it's working_, cuz you really do get much faster builds.

I have to call bullshit on this claim.

CMake is at its hear a build system generator. It offers a high-level abstraction to define software projects, and it uses that abstraction to generate the actual build system. It can generate makefiles, but also Ninja, Xcode, visual studio, and even msbuild projects.

What actually does the build is not CMake, but make, msbuild, ninja, Xcode, or visual studio. Not CMake.

You run CMake once to generate the build project, and when you actually want to build the project you only call ninja or make etc.

To top that off, some of these build systems support build cache systems such as sccache or ccache. Plugging in one of these tools can easily drop build times to a fraction of the time. Literally. I had C++ projects which used CMake whose build time of a complete rebuild dropped to 15% of it's original time.

I haven’t been able to get Bazel to work passively for small, non-toy Go projects—I’m sure it’s something I’m doing wrong, but Bazel is a complex beast to operate. It’s far more complicated to use than Cargo.

use bazel if you're compiling large C++ or Java projects. If you're using rust, use cargo.

Nothing beats a language's own dedicated packaging system (yes, even python's mess is better than bazel+python) but C++ and Java have bad build systems, so bazel is better for them

Granted, but the context of the thread was that C++ build tools are low quality compared to other ecosystems, and you mentioned that Bazel was supported and "quite good" implying that it was comparable with other language ecosystems (perhaps that's not what you intended to communicate?). I believe that it's better than CMake, but the original point (C++ lacks good build tooling compared to other languages) still stands IMHO.

> but C++ and Java have bad build systems, so bazel is better for them

What is wrong with Maven or Gradle?

> Cmake is the de-facto option and is an ancient horrible mess that feels like a miracle if it works at all. What's left?

There is build2[1], which tries to approximate Cargo's experience for C/C++ projects while providing more depth, especially in the build system (unfortunately the "build by convention" ship has sailed for C/C++ so there needs to be some flexibility).

As some indication of the project's "seriousness" (there are a lot of toy build systems out there), it builds Boost and Qt (both 5 and 6 but only classic for now).

[1] https://build2.org

Bazel! It's a modern horrible mess that feels like a miracle if it works at all. Nicer than CMake or Autotools or handcrafted Makefiles though.

> Cmake is the de-facto option and is an ancient horrible mess that feels like a miracle if it works at all. What's left?

I've been working with C++ for a few years and did some work porting legacy apps to CMake. I've saw awful CMake legacy projects but since CMake 3.0 and the introduction of it's declarative way of setting up targets CMake is actually quite nice to work with.

What exactly does CMake do that you feel is "an ancient horrible mess"? Can you provide any specific example?

> What's left?

Rather marginalized but https://waf.io/

Premake is left. We use it across our entire C++ codebase, which is reasonably large.

cmake is fine. just learn modern cmake. most of the complaints are from pre-3.11.

Reply on news.ycombinator.com