Migrating to Bazel symbolic macros(tweag.io)
tweag.io
Migrating to Bazel symbolic macros
https://www.tweag.io/blog/2025-11-20-migrating-bazel-symbolic-macros/
11 comments
I wish tools like CMake and Bazel simply used Lua, Python or JavaScript for their configuration instead of making their own languages with numerous quirks. There's literally no benefit of doing that.
Starlark is a subset of Python that's only primitive recursive. And in a distributed build system, being able to guarantee termination is a very good thing. It also means Bazel can do predictable fan-outs of builds. Starlark has very good reasons for existing.
CMake almost ended up using Tcl, but it was rejected because that would've introduced an external dependency, running counter to what they were trying to achieve at the time. Would Lua have been a good alternative to creating their own (rather janky) language? Sure, but Lua had very little mindshare in 2000. Even with the weird configuration language it has, it's still preferable to the horrible agglomeration of m4 macros that is Autotools.
If you want to pick on any build system for not picking an existing language, Meson would be a better target, as it's similar to but not Lua, and a suitable subset of Starlark-esque subset of Lua would've been useful.
CMake almost ended up using Tcl, but it was rejected because that would've introduced an external dependency, running counter to what they were trying to achieve at the time. Would Lua have been a good alternative to creating their own (rather janky) language? Sure, but Lua had very little mindshare in 2000. Even with the weird configuration language it has, it's still preferable to the horrible agglomeration of m4 macros that is Autotools.
If you want to pick on any build system for not picking an existing language, Meson would be a better target, as it's similar to but not Lua, and a suitable subset of Starlark-esque subset of Lua would've been useful.
Bazel uses Starlark, which is pretty much a deterministic subset of Python. Using Python directly would not be a good idea.
Lua, by virtue of being thread oblivious - may work, but under the curtain (calling "C" code) there is nothing to protect you against thread-safety related issues.
Python "deals" with it
All three options though are full blown Turing-complete languages - e.g. they can loop forever. You don't want that in CI, or a build system.
Starlark is concurrency safe. Top-level global values, once initialized, are frozen (read-only), hence they can be safely accessed by multiple threads. There are no "global" effects (AFAIK), apart from actually doing I/O by calling actions (processes, etc.)
Blaze (bazel's parent) used Python, and had these non-hermetic issues, because you can do anything with Python (actually "Lua" might be easier to sandbox, but maybe python too - not sure).
Point is, starlark is well suited for this job. It wasn't - "Hey let's design this new language". It's really Python but with limited powers for a reason, to enable other unlimited powers (concurrency, avoid recursion, etc).
Python "deals" with it
All three options though are full blown Turing-complete languages - e.g. they can loop forever. You don't want that in CI, or a build system.
Starlark is concurrency safe. Top-level global values, once initialized, are frozen (read-only), hence they can be safely accessed by multiple threads. There are no "global" effects (AFAIK), apart from actually doing I/O by calling actions (processes, etc.)
Blaze (bazel's parent) used Python, and had these non-hermetic issues, because you can do anything with Python (actually "Lua" might be easier to sandbox, but maybe python too - not sure).
Point is, starlark is well suited for this job. It wasn't - "Hey let's design this new language". It's really Python but with limited powers for a reason, to enable other unlimited powers (concurrency, avoid recursion, etc).
Buck 1 used Python directly and it had lots of issues compared to Starlark.
Is anyone really using bazel outside Google in any meaningful capacity? There used to be a number of really popular and widely used projects such as closure compiler, gwt/j2cl, guava and other Java libs, and supposedly lots of golang stuff (not to speak of k8s where people seem to be satisfied it's a black box) that are dying behind bazel walls.
> Is anyone really using bazel outside Google in any meaningful capacity?
Yes. For instance, Stripe uses Bazel internally for ~all of its builds. https://stripe.com/blog/fast-secure-builds-choose-two
For other users, you might peruse the Bazelcon 2025 schedule, which happened earlier this month: https://bazelcon2025.sched.com/
Yes. For instance, Stripe uses Bazel internally for ~all of its builds. https://stripe.com/blog/fast-secure-builds-choose-two
For other users, you might peruse the Bazelcon 2025 schedule, which happened earlier this month: https://bazelcon2025.sched.com/
“dying behind bazel walls” is a bit dramatic when it’s a freely available tool that anyone can learn and use.
imo, it’s also among the very few options that try to solve the hard problems of build systems (alongside Buck and maybe Nix).
imo, it’s also among the very few options that try to solve the hard problems of build systems (alongside Buck and maybe Nix).
Open source projects? Maybe less so.
But there are definitely companies that use Bazel in a major way.
But there are definitely companies that use Bazel in a major way.
I lost a month to Bazel a few years ago. The documentation had so many holes and what was there was either out of date or wildly inaccurate. You could not produce an Angular build using the tutorials as written. Everything was wrong. I'm sure Bazel great if you have a team of people to write bespoke libraries on top of it for each of your targets. I ended up using turbo for frontend and uv workspaces on the backend.
The Swiss company I work at (~300 employees) maintains a monorepo with projects in multiple languages that is managed with Bazel.