[steeve]

To each their own I guess.

I’ve been using it for the last 2 years, and I am not doing any project again without it.

Bazel is not that complex if you start a project with it. Migrating to it and learning it at the same time will be hard though since you’re likely to uncover a lot of skeletons.

[jacquesm]

This comment is not internally consistent.

[steeve]

How so?

[jacquesm]

> Bazel is not that complex if you start a project with it.

Bazel is quite complex and when you start a project you do not yet need it, rarely will an organization start with something like Bazel, they use it because - you hope - they need it.

vs:

> Migrating to it and learning it at the same time will be hard though since you’re likely to uncover a lot of skeletons.

So the bulk of Bazel use cases will revolve around migrating an existing build system to use Bazel instead, and that is hard, because Bazel is difficult and has a very steep learning curve, and requires a lot of work to keep it running.

Tooling should adapt to use cases, if you need to adapt your use cases to the tooling then that's a fault of the tool. If that limits use of the tool to those projects that are started with it then you have already lost the vast majority of your potential audience. So yes, if you start using Bazel right from day #1 then that might be the way to go. But I suspect - and so far have not seen any evidence - that that is the way it is actually used.

[steeve]

It is true that you rarely start with a new build system.

Bazel is hard in the same way Rust is hard. If you port your existing project to it, chances are you will run into issues because you were doing things wrong with respect to hermeticity or reproducibility. It goes really far to make things correct. You may not need it, but when you do it’s a godsend. Or at least it was for a lot of people I talked to. And my own experience as well.

If your project is vanilla enough, things will go mostly smoothly and the benefit will be immediate (ie bazel clean is a legend).

Think of Bazel as a framework. If you do thing its way, it will spoil up. But sometimes a framework is not what you need. That said, if you’re happy with your current system, then good for you!

[jacquesm]

I just don't see a new company starting up that one day will need Bazel doing that with Bazel. There is just too much overhead, you won't ever become that company that needs Bazel if you start out that way.

[steeve]

That is a bold statement.

This is not only related to the size of the company but rather the size of the project. For instance if the project requires polyglot build or codegen (gRPC does both for instance), Bazel will shine and save a lot of time and headaches.

That’s not to say that it’s without its problems and that some use cases are very rough around the edges. Which is something the team and community are working to fix.