Buck

Buck is a build system developed and used by Facebook. It is very similar to Bazel in its design and goals, emphasizing high-performance, reproducible builds for large, multi-language codebases. It encourages the creation of small, reusable modules that can be built in parallel.

Buck2 is an extensible, multi-language build system developed and used by Meta, and written from scratch in Rust

  • Designed for large monorepos, it focuses on fast, reliable, and hermetic builds by optimizing for parallelism, incremental processing, and integration with remote execution.
  • Like other large-scale build systems, Buck2 uses a build graph of dependencies to determine what needs to be built and when. Projects are defined using a declarative, Python-like language called Starlark, with build files typically named BUCK.
  • Comparison: Buck2 vs. Buck1 Buck2 is a complete rewrite of its predecessor, Buck1, and offers significant improvements in performance and design.

Comparison: Buck2 vs. Buck1

Buck2 is a complete rewrite of its predecessor, Buck1, and offers significant improvements in performance and design. 

Feature Buck1 Buck2
Performance Slower; incremental builds could still incur significant overhead even with no changes. Substantially faster. Meta observed builds completing twice as fast internally. Rebuilds with no changes are nearly instantaneous.
Core language Written in Java. Written in Rust, which offers performance benefits by avoiding garbage collection pauses.
Rules language Rules were written in Java and were tightly coupled with the core build system. All rules are written in the Starlark language and are external to the core, which makes rules development simpler and faster.
Build graph Maintained multiple distinct graphs (e.g., target graph, action graph), which could lead to entire graphs being invalidated. Uses a single incremental dependency graph, which allows for more fine-grained invalidation and greater parallelism.
Remote execution Treated local execution as the default, with remote execution added later. Trusted CI builds could write to the shared cache. “Remote execution first.” Local builds are treated as a special case of remote execution. All developers can contribute to the shared cache, improving cache hit rates.
Hermeticity Not hermetic by default, and missed dependencies were often overlooked.. Enforces hermeticity by default, with missing dependencies resulting in build failures.

Comparison: Buck2 vs. Bazel

Bazel was inspired by Google’s internal build system, Blaze, and Buck was inspired by Blaze as well. Both are artifact-based build systems designed for large, multi-language monorepos and share many high-level concepts. 

Feature Buck2 Bazel
Core language Written in Rust, which is generally considered more modern and performant. Primarily written in Java and C++, with an older, larger codebase.
Core-rules separation The core is entirely language-agnostic. All language-specific rules (like C++ and Java) are implemented externally in Starlark. Has some core rules for common languages built-in to the Java kernel. Migrating these to Starlark is an ongoing process.
Incremental builds Uses a single, unified dependency graph for better incremental performance and parallelism. Features like dynamic dependencies allow rules to adapt the build graph at runtime for certain languages. Historically used a phased approach (loading, analysis, execution). Though it is moving toward a more unified system with projects like SkyMeld, it can suffer from performance issues on large-scale changes.
Remote execution Built with remote execution in mind, supporting the same protocol as Bazel. However, local builds are not sandboxed by default. Well-known for its remote caching and execution capabilities. Local builds are sandboxed by default.
External dependencies Uses a concept called “cells” to manage external dependencies, which are often integrated via Git submodules or vendoring tools like Reindeer for Rust. Downloading from URLs is allowed in regular rules. Uses “workspaces” and “repository rules” via the WORKSPACE file, and is transitioning to the new bzlmod system. Repository rules run in a separate, less-isolated phase.
User experience Features a modern, fast, and responsive terminal UI designed with a clean experience in mind. The CLI is generally considered less snappy than Buck2’s. Historically, the WORKSPACE file has been a source of frustration.
Ecosystem Still a relatively young open-source project with a smaller ecosystem of rules and tooling compared to Bazel. Mature ecosystem with a large collection of community-developed rules for many languages and tools.