Bazel was first announced and made open-source in early 2015, but by that time Domino had already been in development for at least a year. I remember following the early internal discussions at Microsoft on the One Engineering System or "Apex" initiative which first provided the impetus for what became Domino; some of those discussions were quite animated :P

Also, while I don't know BuildXL and Bazel well enough to compare their goals and relative strengths, I will say that BuildXL was developed at Microsoft, which has historically had a great diversity of build toolchains and workflows across all its software products. Just on the toolchain side, Microsoft has many different build engines/make tools, unit test frameworks, tools and conventions to register an automated test to run on a certain schedule (for products too big to run every test on each and every build), build and test server farms, continuous integration tools to orchestrate those server farms, tools to email people and/or file bugs on test failures, and so on...

From my limited understanding, Google has never been this way at all, and so some of the lessons and ideas incorporated into BuildXL may seem strange to Bazel's designers.

(I work at Google and have contributed a very tiny bit to improving Bazel on Windows, though it is not related to my actual work at Google.)

I am yet to see what Bazel does better, beyond faster Android builds, which is quite easy given Gradle and how Android team implements their plugins.

So far the key differences from maven, which I am most familiar with, are:

* The module format is much lighter, making it more practical to split a project into thousands of modules, which can then be built incrementally. This leads not just to faster build times, but finer-grained tracking of dependencies between modules

* The driving factor for us: Bazel has built-in support for specifying the sha256 hash of external dependencies. Verifying authenticity of external dependencies is not possible in maven without significant extra work. In Bazel it's built in.

* Much easier to set up bazel targets to perform once-off tasks like seeding a local database through your build system. While can you can do this with maven, you usually had to resort to plugins and the declarative style made it complex. Most maven projects I worked on had external shell or python scripts for these sorts of tasks.

For me personally the biggest downside has been that it takes over enough of the build-system responsibilities in IntelliJ that other tooling I'm used to that integrates with the IDE, such as Chronon or JRebel, doesn't work.

Bazel has a steep enough learning curve and enough additional complexity that I probably wouldn't recommend it for most projects unless you are at a certain size and complexity level where you can benefit form it.

>> Bazel has a steep enough learning curve

I'd argue for basic tasks it has far less of a learning curve than e.g. Gradle or, god forbid, something like CMake.

Anyone know of anything similar but without that steep learning curve?

The only catch is that while the language and tools are simple, Nix is really a pure functional language and you have to treat your build process like code rather than config. It's easy to go down rabbit holes...

(I considered Bazel but it's very half-baked and lacks all of Blaze's proprietary toolchain support.)