Buck2: A Fast, Hermetic, Multi-Language Build System with a Rough Edge

The Problem: Multi-Language Builds Without the Glue

Most build systems force you to stitch together language-specific tools: make for C, cargo for Rust, pip for Python. Each has its own interface, its own cache, its own way of tracking dependencies. Buck2 attacks this by being a single build system designed from the start for multiple languages. The README gives a concrete example: a Python library can depend on an OCaml library, and that OCaml library can depend on a Rust crate, all built with one tool and one consistent user experience. That is the core problem it solves. It is for teams that have complex inter-dependencies across languages and want a unified way to build, test, and integrate components. If you only build in one language, a dedicated tool might serve you better, but the moment you cross language boundaries, Buck2's abstraction becomes relevant.

How It Works: Critical Path Calculation and Hermeticity

Buck2's speed comes from calculating the critical path of your build graph and minimizing overhead. The README claims it is up to 2x faster than Buck1 in practice, though it notes that comparisons with Bazel have not been performed. That number comes from Meta's internal usage, not from external benchmarks, so treat it as an upper bound. Hermeticity is enforced only when using Remote Execution. In that mode, a build rule must correctly declare all of its inputs; if a .c file needs a .h file that is not specified, the build fails. This is a design choice that prevents a whole class of 'works on my machine' errors. However, the README explicitly states that local-only build steps are not sandboxed, so hermeticity is not guaranteed unless you use Remote Execution. This is a fundamental trade-off: you get correctness guarantees at the cost of requiring a remote execution setup.

Language-Agnostic Core and Scriptability

The Buck2 core executable is language-agnostic, with a small API. Even C/C++ support is written as a library, not baked into the core. This means users can implement support for new languages themselves, making the system incredibly flexible. The README highlights that users can write everything from scratch if they want. This is a departure from many build systems where language support is hardcoded. The 'Buck Extension Language' (BXL) allows for self-introspection of the build graph, enabling tools like LSPs or compilation databases to inspect and run actions. This is a concrete mechanism for automation that goes beyond simple build commands. The design is inspired by modern theory of build systems and incremental computation, which suggests a solid foundation, though the README does not detail that theory.

Getting It Running: Downloads and Dotslash

You can get Buck2 by downloading a bi-monthly version or the 'latest' built binary for your platform from the GitHub releases page. The 'latest' tag is updated on every push to the repository, so it is always a recent commit. Alternatively, you can use dotslash, a tool that deploys a single text file into your repo and auto-pulls the correct platform-specific binary. The README does not provide a direct installation command like a package manager, so you must rely on these manual methods. The Getting Started guide is linked on the homepage, which presumably contains more detailed setup instructions. There is no mention of configuration keys in the README, so expect to consult the docs for that.

The Rough Terrain: No Stable Release and Missing Features

The README is blunt: Buck2 does not have a stable release tag. It is used extensively inside Meta, but outside consumers will encounter rough edges. Several features are missing or in progress, some Buck1 toolchains are missing, and you will likely have to fiddle with things more than necessary to get it polished. This is a genuine limitation. The project is not archived, but the last push was in 2023, which might indicate a slowdown in public activity, though the README suggests that Meta tracks HEAD continuously. The warning is clear: your mileage may vary, and tracking HEAD is ideal for submitting bug reports. This is not a tool for teams that need stability; it is for those willing to live on the edge and contribute fixes.

Alternatives: Bazel and Pants, with Real Differences

Buck2 is not the only multi-language build system. Bazel and Pants are direct alternatives, and the README says Buck2 will feel familiar to users of those systems. The key difference is in the approach to language support and hermeticity. Bazel also supports multiple languages and has a similar remote execution API, which Buck2 uses for distributed compilation. Pants is another option, but it may not offer the same level of language-agnostic core design. Buck2's core is totally language-agnostic, with even C/C++ support as a library, whereas Bazel has built-in language rules. That means Buck2 is more flexible for custom language support, but it also means you have to do more work if a language is not already covered. The README notes that existing remote execution solutions like BuildBarn, BuildBuddy, EngFlow, and NativeLink work with Buck2, so you can leverage existing infrastructure if you already use Bazel's remote execution API.

Maintenance and License: What to Expect

The license is listed as Apache-2.0, but the README badge shows 'MIT OR Apache-2.0', so you have a choice of license, which is permissive for commercial use. Maintenance is a concern: the project is not archived, but the last push was in 2023, which could mean the public repository is less active than the internal version. The README says Meta uses the latest committed HEAD, so the internal version is actively maintained, but external contributions may be less encouraged. There is no mention of a long-term support policy or upgrade path. Given the lack of stable releases, you must be prepared to track HEAD and handle breaking changes. The prelude code is the same as used internally, which is a good sign for quality, but it does not guarantee a smooth experience for external users.

Who Should Adopt It: A Specific Verdict

Buck2 is for engineers who manage ultra-large repositories with multiple languages and are willing to trade stability for speed and flexibility. If you are already familiar with Bazel or Buck1, the learning curve is manageable. You should adopt it if you can handle the lack of a stable release and are prepared to debug rough edges. You should not adopt it if you need a build system that is guaranteed to work today without intervention. The README's own warning is the best summary: consider the code battle-tested, but expect to fiddle with things. Before adopting, verify that your toolchains are supported and that you can use Remote Execution if you need hermeticity. The project's future depends on Meta's internal usage, so as long as Meta relies on it, it will continue to evolve, but external users must be self-sufficient.

Editorial conclusion

Adopt Buck2 if you manage a large, multi-language monorepo and are willing to track HEAD, accept rough edges, and possibly contribute fixes. Do not adopt it if you need a stable, polished build system with a guaranteed upgrade path. Before adopting, verify that your toolchains are supported and that you can handle the lack of a stable release tag. Check the Getting Started guide and test with a small project first.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes