Is it wrong to say that for 95% of the internet that isn’t FAANG, bazel is a solution in search of a problem? I’ve never once seen or used a build system so unnecessarily complex. If you’re a 100k software company it makes a lot of sense to build in complexity but for the majority of the internet, why is something like Bazel any better than existing, simpler build tools?
jmmv•4mo ago
Bazel is complex, yes, and in my opinion not suitable for small, one language projects.
But I’ve seen many builds, outside of FAANG, that are too slow and that also break frequently after a simple “git pull”. Which other systems promise to improve those, and how do they do it?
hansvm•3mo ago
Bazel solves a ton of problems other systems don't, but it introduces a ton of its own. If you can afford (or are currently accidentally affording) 2-3 FTEs managing builds, that's all you need to scale Bazel indefinitely and solve basically all of the rest of your build problems. If you can't afford a dedicated Bazel team then it's absolutely not worth using on anything more than a single "team" (people talking to each other every day, a dedicated Bazel xoogler, probably 5-13 people).
As to the actual "why", even little things like BUILD files requiring you to enumerate dependency graphs gives you a leg up that you _can_ implement in other build systems, but likely won't. Whether you're a "monorepo" or not, you still have all your code living _somewhere_ as a monorepo, and the only question is how good your tooling is. How easy is it in your system to "run all tests properly depending on the set of changed files"? That's easy in Bazel and hard in every other solution I've seen (possible of course, but those sorts of constraints aren't the happy path for other build systems, so teams don't tend to build that way without a very solid lead imposing that strategy).
wredcoll•3mo ago
I've recently had bazel inflicted on me.
I don't get it, at all.
What should I read that will make me happier at having to use it?
eximius•3mo ago
It's mostly happy for people who don't have to deal with it.
If you are an "end user" who just wants to run your damn code without caring about your dev environment, then `bazel run|build|test //thing/to/run:target` is about as good as you can get! _If bazel is already set up_, I don't have to worry about my environment! It just works.
If your environment has a lot of churn and there isn't a team who makes sure bazel is actually configured correctly, then, yea, it is massive overkill for a lot of things and if you try to do things how you normally would and not the bazel way, you'll have a bad time.
There are other benefits - sometimes you want public APIs so it _can_ be used, but you want visibility rules to limit _who_ can use it. It is great for it's cacheability and dependency tracking - if you need advanced build tooling, it has what you need!
But there is a very real chance you don't need any of these things and so the cost is not worth it.
(I, personally, hate dev environment churn, so just having the CLI tooling uniformity is enough for me.)
eximius•3mo ago
Why does this 1 hour old post have comments from 29 days ago?
dogleash•3mo ago
Mods sometimes merge posts. Whether any particular merger makes sense can be a bit of a toss-up.
jjmarr•3mo ago
I would like to try bazel for its remote execution capabilities on a Conan+Cmake project but I keep hearing that it's all-in or nothing.
eej71•3mo ago
At the very least, bazel would devour the cmake responsibilities in this case. That's not intended as a criticism of either. Just a description of bazel. It can feel very Star Trek Borg like.
jjmarr•3mo ago
The challenge is I'd have to convert our whole system to bazel. That's a bit of a hard sell when I don't know how easy it is.
SlightlyLeftPad•4mo ago
jmmv•4mo ago
But I’ve seen many builds, outside of FAANG, that are too slow and that also break frequently after a simple “git pull”. Which other systems promise to improve those, and how do they do it?
hansvm•3mo ago
As to the actual "why", even little things like BUILD files requiring you to enumerate dependency graphs gives you a leg up that you _can_ implement in other build systems, but likely won't. Whether you're a "monorepo" or not, you still have all your code living _somewhere_ as a monorepo, and the only question is how good your tooling is. How easy is it in your system to "run all tests properly depending on the set of changed files"? That's easy in Bazel and hard in every other solution I've seen (possible of course, but those sorts of constraints aren't the happy path for other build systems, so teams don't tend to build that way without a very solid lead imposing that strategy).
wredcoll•3mo ago
I don't get it, at all.
What should I read that will make me happier at having to use it?
eximius•3mo ago
If you are an "end user" who just wants to run your damn code without caring about your dev environment, then `bazel run|build|test //thing/to/run:target` is about as good as you can get! _If bazel is already set up_, I don't have to worry about my environment! It just works.
If your environment has a lot of churn and there isn't a team who makes sure bazel is actually configured correctly, then, yea, it is massive overkill for a lot of things and if you try to do things how you normally would and not the bazel way, you'll have a bad time.
There are other benefits - sometimes you want public APIs so it _can_ be used, but you want visibility rules to limit _who_ can use it. It is great for it's cacheability and dependency tracking - if you need advanced build tooling, it has what you need!
But there is a very real chance you don't need any of these things and so the cost is not worth it.
(I, personally, hate dev environment churn, so just having the CLI tooling uniformity is enough for me.)