From their FAQ: >Why use Please instead of Bazel, Buck or Pants?

>All four of these systems are quite closely related in the scheme of things, being inspired by (or in Bazel's case, a direct open sourcing of) Google's Blaze.

>Several of us had worked at Google and used Blaze extensively there; we were excited about it being open sourced as Bazel but by then we were already using Please internally. It's a great system but we have slightly different goals, specifically we're aiming Please at being lighter weight and pushing the boundaries of what can be done within the BUILD language. Since Please is written in Go there's no runtime dependency on the JVM.

>We actually used Buck for some months internally before deciding to write Please and before it was capable of building our repo. We preferred it to other options available, but again we're focused on different goals; Please is easier to extend to new languages, has a bunch of features that we specifically wanted (e.g. test sandboxing) and has a stronger focus on BUILD language correctness. Conversely we have much less support for mobile development.

>We're least familiar with Pants; one of our developers briefly tried it and while we liked many aspects we didn't think it was the ideal fit for us at the time.

That's a lot of text to say three things: doesn't use JVM, has test sandboxing, and the DSL is "more correct". This doesn't tell me what I want to know.

I've only used Bazel in anger (in a medium-small sized project); I've found it really frustrating because it effectively has two separate languages (inside build files and in custom rules), even though it's both Starlark. It's especially terrible for doing things that Bazel didn't already know about (i.e. running shell commands to generate things, even if you could tell Bazel all the inputs and outputs).

We wanted to switch away from Bazel because of the mismatch; it looked like Pants and Buck had the same issues. At the time Please didn't have sensible documentation so it was skipped. From what they have now it seemed like it's more reasonable in this respect, but I don't actually know yet; perhaps somebody who knows can chime in?

What do you mean? Genrules are very good at running she'll commands (or even entire executables).

By custom rules do you mean macros, or full on custom rules?

Genrules are okay for commands, but most things I want to do end up being tiny shell scripts, which isn't a great fit.

I mean full on custom rules, exactly because of the inability for genrule to span more than one command (so we end up having to generate tiny shell scripts and running them).

I've also had issues debugging things any time I've tried to use genrule; the error messages tend to be unhelpful in my experience (though that's been a while and I don't recall the details). Things that look like they'd do what I want would just not work in unhelpful ways, and interrogating the system usually didn't work until there were no errors (at which point I wouldn't need to interrogate it anymore…)

Genrules can run shell scripts though, like most of the time my genrules invoke an arbitrary python script. Shell would work much the same.

What do you mean by a "command"? I'm very confused by the nomenclature here.

I hate bazel with passion, I have to use it at work on really large project, and the UX is so wrong... built for google by google and my CTO thinks we can be google if we use it...

What specifically about the UX is annoying to you? I'd be interested in hearing what could be done to improve the experience. Is it just writing BUILD files or is it the cli interface?

Some people really dislike the JVM, and Please is written in Go.

Exactly what I was about to say. Bazel is a monstrosity in terms of how much shite it pulls in to get started.

Is it a monstrosity? You need the JVM but the JVM doesn’t seem like a monster to me.

Bazel doesn’t need the JVM as it’s built into its self contained binary.

Hm, I guess my point was that it still needs the JVM, it just uses the bundled version. I guess that wasn’t clear.

Yes, but the bundled JRE is slimmed down, to the point where, last I checked, the bazel standalone binary is ~50Mb.

50mb.

"slimmed down"

lol.

You might not want to look at some golang binaries ;)

The JRE is 655.8M on my system.

And I would have considered that to be large 20 years ago, because it would have filled an entire CD-ROM disc, and it would have taken over five hours to download.

However, I still have somewhere over 100 GB free on my seven-year-old laptop, and the download will take me ~40 seconds.

But even if the 600MB were a problem, Bazel doesn’t need an external version of the JVM. It bundles its own, and fits the whole thing in under 50MB. Some people are under the mistaken impression that you have to install the JVM first and then install Bazel, which is simply not true.

Good to know that you live in a privileged place and access a fast internet connection. Most of the places don't have that kind of bandwidth [1] to download 600 MB of file in 40 seconds. Also, Bazel needs a huge amount of RAM because of JVM and runs a daemon process in the background to speed up the build duration. Running a background JVM daemon process is a NO for me and Bazel wastes system resources.

[1] https://en.wikipedia.org/wiki/List_of_countries_by_Internet_...

> Most of the place don't have that kind bandwidth…

Most people don’t have the kind of bandwidth it takes to download a 50 MB binary? Are we still talking about Bazel here, because that’s the size of the download. What about tools like compilers? You have to download those, too.

> Running a background JVM daemon process is a NO for me and Bazel wastes system resources.

What system resources does it actually use up? A half-gig of RAM? This kind of optimization is penny-wise and pound-foolish. You are spending your precious time and energy worrying about a resource whose marginal cost to you is about the same as a cup of coffee.

I run Bazel on a terribly obsolete, seven-year-old laptop which is my daily driver. Sometimes Chrome will choke on a website, sometimes I'm waiting ages for Homebrew to update or for NPM to download some packages, but Bazel is not a problem.

> You are spending your precious time and energy worrying about a resource whose marginal cost to you is about the same as a cup of coffee.

I don't install tons of random garbage because I want to know and understand what is running on the hosts that I maintain.

I need to be able to debug the stuff I run, and complexity makes it difficult.

Tenths of MB of stuff is complexity. Tenths of build time or run time dependencies is complexity. A compiled tool when a script would have been sufficient is also complexity.

> I need to be able to debug the stuff I run, and complexity makes it difficult.

Bazel is way easier to debug than Make. Debugging a decent-sized build system made with Make is just an exercise in suffering.

I am… honestly… no longer interested in understanding the entire software stack. I understand my time on this earth is limited and want to spend it doing other things. With Bazel, I am spending less time fucking around with build systems and more time doing the stuff I care about.

> Tenths of MB of stuff is complexity. Tenths of build time or run time dependencies is complexity. A compiled tool when a script would have been sufficient is also complexity.

As someone who still writes C, I can understand the joy that people feel when you make some cool program and it’s measured in KB, not MB. However, what you’re describing strikes me as fetishistic.

That 600 MB is mostly standard library, and reusing it makes every app smaller. Statically linking everything creates size and version skew problems that I hoped we had left behind in the 1980s.

So you can't spend a one time cost on the scale of downloading Vim 10 times?

50mb for a build tool is still ludicrous. Very few product codebases will ever reach that size.

In my experience there is a strong correlation between executable size and how hard it is to unravel any issue that arises in it.

> In my experience there is a strong correlation between executable size and how hard it is to unravel any issue that arises in it.

Bazel bundles the JRE, that’s why it’s 45 MB.

The correlation is kinda beside the point, though, because my experience with Bazel is that it’s easier to unravel issues with Bazel than unravel issues with Make, and Make is much smaller.

Bazel has its JRE built in its self contained binary. Not sure what you’re referring to.

I also was trying to figure out why I would use this over Bazel. Then I remember reading a story yesterday about how ex-googlers miss their tooling when they leave. Their CTO is an ex-googler, so maybe this is the reason.

But Bazel is developed by Google itself right now. Presumably if you missed Google tooling you'd rather use Bazel, no?

I'm not suggesting Bazel is perfect: I think e.g. Starlark's insistence on being a separate language does more harm than good. (FWIW I also think the JVM objection is a little silly.) But I am saying preferring the Google tooling would ostensibly mean you like Bazel a lot already :)

I've read Bazel without the rest of Google tooling (giant monorepo of everything, distributed build farms, etc) the experience is nowhere near the same.

What do you mean with "insistence on being a separate language"? Many build tools have their own DSL.

Starlark is _almost_, but not quite_ Python, and Python 2 at that. You could do everything Starlark does in actual Python and get stuff like static type checking for free.

I think the term DSL is overloaded here? Consider all the Lisp and Ruby stuff that's definitely DSL but doesn't need most of a language implementation.

In a word: simplicity

Bazel has a lot of magic and crazy abstractions. Please is far easier to get your head around and as a result, far easier to bend to your iron will.

Please predates Bazel IIRC. It just didn’t gain as much traction. Please seems considerably easier to operate, but it doesn’t enjoy Bazel’s rigorous usage (although I’ve only encountered bugs when trying to use Bazel to build Python 3 projects).

Bazel’s Python integration quality is a level down from its Java, Go, and C++ integrations. It’s getting better though.