This is a build system produced by Neil Mitchell, one of the authors of Build systems a la carte, and author of Shake. It has a good pedigree, and is well thought out.
The starlark library it uses has some nice extensions like type annotations, an LSP, linter, etc. The trend of Meta’s open source Rust projects spawning good libraries continues (see also sapling which has components used by git-branchless).
I haven’t managed to dig into their incremental computation engine DICE too much yet but my understanding is that it’s inspired by work on Shake, Salsa, Skip, and Adapton
From the start a large part of the rule footprint seems to be written in starlark as opposed to using built in rules. Bazel has been going in this direction and Please did this from the get go but it’s great for rule authors to be able to inspect the native rules for inspiration and learning.
It seems it will be taking a Gazelle based approach to language ecosystem integration (see reindeer for Cargo integration) as opposed to a more dependency inference based approach like Pants. Though there was no reason to suspect this approach would be considered, there are some definite ergonomic benefits.
It seems it will be taking a Gazelle based approach to language ecosystem integration (see reindeer for Cargo integration) as opposed to a more dependency inference based approach like Pants. Though there was no reason to suspect this approach would be considered, there are some definite ergonomic benefits.
I’m curious what you think the ergonomic benefits are for this approach? From my experience with Gazelle the upside is Go integration with other facets of the Bazel ecosystem, but the ergonomics are worse than directly using the Go toolchain.
I was mainly referring to Pants’ dependency inference when referencing ergonomics. This can be a lot nicer than having to maintain dependency references between files.
That being said, the biggest ergonomic benefits of something like Gazelle over the native toolchain is speed. The ability to run a single command to compile, lint, and test everything in a loop but only what changed is great. Go is pretty good in this space already, but some tools can be a bit bad with detecting incremental changes and only running new things.
Ah yeah, a Facebook rust project. Be prepared to rigorously follow the exact nightly rustc version they are on each week (apparently no plans to use stable rust even in their fundamental utility library exist).
Facebook hired a bunch of googlers who liked Blaze (Google’s internal version of Bazel). Because blaze wasn’t open source at the time, they wrote a clone called buck.
I was out of Bazel by the fact that it depends on both Java and Python. A rust reimplementation that produces a statically linked binary for the build tool sounds attractive.
This is a build system produced by Neil Mitchell, one of the authors of Build systems a la carte, and author of Shake. It has a good pedigree, and is well thought out.
Some interesting notes on Buck2:
I’m curious what you think the ergonomic benefits are for this approach? From my experience with Gazelle the upside is Go integration with other facets of the Bazel ecosystem, but the ergonomics are worse than directly using the Go toolchain.
I was mainly referring to Pants’ dependency inference when referencing ergonomics. This can be a lot nicer than having to maintain dependency references between files.
That being said, the biggest ergonomic benefits of something like Gazelle over the native toolchain is speed. The ability to run a single command to compile, lint, and test everything in a loop but only what changed is great. Go is pretty good in this space already, but some tools can be a bit bad with detecting incremental changes and only running new things.
Ah right, it wasn’t clear to me what “this” was referring to, but I see you were referring to the opposite of what I interpreted!
Yeah I agree, I love the static analysis approach. I’d love to see a build tool double down on this. I’ve played around a bit with it myself.
Ah yeah, a Facebook rust project. Be prepared to rigorously follow the exact nightly rustc version they are on each week (apparently no plans to use stable rust even in their fundamental utility library exist).
I failed to understand what is Buck exactly - is it alternative to meson/bazel?
It’s worth reading the Buck2 explainer. It’s a really promising exploration of monadic build systems (ala. Shake, llbuild2) at Bazel scale.
Facebook hired a bunch of googlers who liked Blaze (Google’s internal version of Bazel). Because blaze wasn’t open source at the time, they wrote a clone called buck.
I was out of Bazel by the fact that it depends on both Java and Python. A rust reimplementation that produces a statically linked binary for the build tool sounds attractive.
The subset of Python supported by Bazel (Starlark) does not depend on CPython, it’s interpreted by Bazel itself.
A Python interpreter was used historically but I believe the migration happened before Bazel became open sourced.
The installation instructions say that it depends on: