Buck2 optimizations & dynamic dependencies (Neil Mitchell & Chris Hopman)
All buck2 rules are written entirely in Starlark. There are no special language rules implemented in the Buck2 core.
Meta has an LSP server for Starlark, and a version of Starlark with static types.
Buck2 brought the (average?) build at Meta from 10 minutes down to 5 minutes, and metrics show that this really did result in greater developer productivity. “You make developers’ builds faster, and they write more code. They don’t go to more meetings. They don’t leave work earlier. They actually do more of the useful stuff you are paying them for.”
Meta is using the open source version of Buck2 internally. When developers push changes to Buck2, they are live to the rest of the world within 15 minutes.
BXL (Build Extension Language). Some things, like IDEs, want to interact with the build system to see the target graph, start builds, inspect outputs, etc. BXL is a Starlark API into everything in the build.
Q: Why write Buck2 instead of using Bazel? A: “We would have quite liked to switch to Blaze, but we were considerably less keen on switching to Bazel.” It would have been hard for them to migrate, because they would want remote execution, C++ rules, and Java rules that matched the existing buck1 rules behaviors, and only later would they migrate to standard Bazel rules. These rules are particularly challenging for them to handle, because they are implemented in Bazel core, rather than being implemented in Starlark. It also sounds like they have concerns with the design of Ocaml, Erlang, and Haskell rules.
