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?