Skip to content

SYSTEM Cited by 1 source

Starlark

Definition

Starlark is the configuration language used by Bazel (and by [Buck2, Pants, Tilt, and several other Google-originated build tools]) for BUILD files and build rules. It is a deliberately-constrained dialect of Python: familiar surface syntax, but with limitations that make Bazel's caching and parallelism preconditions enforceable.

Why Starlark is constrained

Bazel's caching (concepts/content-addressed-caching) and parallelism require each action's inputs to be fully declared, each action to be hermetic (concepts/hermetic-build), and each action's output to be idempotent (concepts/idempotent-build-action). If a build rule can quietly read a file from disk, mutate a global, or recurse unboundedly, those preconditions evaporate — the build graph stops being a DAG of cacheable actions and becomes a Python program of arbitrary behaviour.

Starlark excludes, among other things:

  • Arbitrary filesystem I/O inside rule evaluation.
  • Mutable top-level globals.
  • Arbitrary imports (only load() of other .bzl files).
  • Recursion beyond bounded patterns.
  • Most standard-library modules.

The constraints are the point. Slack's Quip/Canvas team leaned on them: when rewriting Python build-orchestration code into Starlark, the language's limitations "aim at ensuring builds meet all the requirements for Bazel to be effective" — and forced the team into shapes that made the resulting build actually cacheable. (Source: sources/2025-11-06-slack-build-better-software-to-build-software-better.)

Starlark as a separation boundary

A second Slack-article insight: writing build code in Starlark, rather than in the application's implementation language (Python, in Slack's case), makes the separation between application code and build code enforceable by the language itself. Application Python can import from application Python; Starlark cannot import from application Python. The coupling path — "build code calls an application module to do build work" — is closed off by the language.

Seen in

  • sources/2025-11-06-slack-build-better-software-to-build-software-better — Slack rewrites Python build-orchestration code into Starlark to sever backend↔frontend coupling, achieving a 60 min → 10 min end-to-end build speed-up. "Starlark is a deliberately constrained language whose limitations aim at ensuring builds meet all the requirements for Bazel to be effective. Building in Starlark helped us enforce a full separation from application code."
Last updated · 470 distilled / 1,213 read