choosing a build system is a really technical choice that's all about the language you code in, not something strategic, right? not necessarily; the same principles that make #Bazel so powerful are showing up in other, broader tools for devops like Helm. but it's too hard to adopt, right? maybe not!
there are hardly any other companies that work exactly like Google, but Google is *really big* and uses a lot of languages, so tools written to help Google, like Bazel, have something for almost everyone Ulf Adams of #Engflow tells me - and almost every org has the 'works on my machine' problem when it comes to debugging.
Bazel promises fast, reproducible builds with artefacts you can cache and reuse and you can get the benefits without having to adopt all the rigour Alex Eagle of #AspectBuild explains to me, while Max Kanat-Alexander (who used to run Google's code health team) tells me why being hermetic and reproducible is so powerful when you can do more of it.
if you're not Adobe, Nvidia, Snowflake, LinkedIn or one of the other big companies adopting Bazel with the resources to do a huge migration, that doesn't mean it's not for you: there are JetBrains and VScode plugins and an entire ecosystem of companies run by people who worked on Bazel and Blaze - like EngFlow and Aspect Build.
Bazel is also a really interesting open source governance story. the usual tension between a founder company that needs to control the tool it relies on and a large and vocal open source community gets a possibly unique solution: an open source project for the engine and a foundation for the rules (written in Starlark, another powerful tool) that will be the voice of the community for Google, Helen Altshuler tells me.
will it work? well, that's the same split as inside Google itself, EngFlow's Luis Pino tells me, so there's a good chance it will,.
https://www.thestack.technology/why-everyone-is-moving-to-googles-bazel-build-system/