Congratulations to the BuildXL team! Domino, incidentally, was/is the internal for BuildXL; there are a few papers published where the system is described under that name. I had the privilege to see it gradually rolled out in the Office codebase over the course of a year or two. It was a massive improvement, and the lengths to which the team went to see it through are really beyond description here.
I _have_ to wonder why we didn't just pick up Bazel, which is Google's open-source distributed build engine for large systems, which also happens to have been stable for years. Perhaps its Windows support wasn't up to snuff at the time, but it feels like that would have been easier to fix that than to build a whole new build system.
Regardless, congrats again! So cool to see this out in the open.
> I _have_ to wonder why we didn't just pick up Bazel, which is Google's open-source distributed build engine for large systems, which also happens to have been stable for years. Perhaps its Windows support wasn't up to snuff at the time, but it feels like that would have been easier to fix that than to build a whole new build system.
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.
Windows support in Bazel is still far from perfect; to this day, you need Msys2 for many things to work. Still, things have been moving forward quite a bit recently, I think in part due to Angular. Honestly, it's still really nice to use imo, but I can see why it would be hard for Microsoft to adopt.
(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.)
You have to wonder though whether the effort spent building Build Accelerator would be better spent fixing Bazel bugs on Windows. Bazel really has no equal on the Linux side, and Google's internal version (+Forge and other systems) is far and away the best dev experience I've ever seen anywhere.
I do Maven for Java and JVM languages, Gradle only because Google forces me to on Android, for better or worse CMake has won for C++ and MSBuild for .NET languages.
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.
I just started working at a shop that uses Bazel for a large-ish Java backend codebase.
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.
I love Bazel, but above all I hope open source can adopt Bazel more. It’s certainly much more usable for the case where you want to import external programs, versus systems like CMake, in my opinion.
Nix is similar to Bazel, supports distributed cache + build + CI (via Hydra), and has a huge amount of existing build support tools. It's not typically used as the only build system though; it's more like glue that wires all your build systems together deterministically. Build steps (derivations) are simple bash scripts executed within a sandbox.
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.)
Bazel has not "been stable for years", perhaps you are thinking of "Blaze"? Bazel is full of brand new code and recent bugs (such as not releasing file handles) suggest it is not yet fully ready for mass adoption.
I _have_ to wonder why we didn't just pick up Bazel, which is Google's open-source distributed build engine for large systems, which also happens to have been stable for years. Perhaps its Windows support wasn't up to snuff at the time, but it feels like that would have been easier to fix that than to build a whole new build system.
Regardless, congrats again! So cool to see this out in the open.