https://blogsystem5.substack.com/p/bazel-next-generation
JMMV shares this thoughts on build beyond bazel, and highlights Ed Schouten (of BuildBarn) and his experiments with Bonanza. Bonanza maintains Bazel compatibility, but is remote execution first, does analysis on the remote workers with a distributed cache to minimize cold builds, and has starlark-only for rules (as with Buck2). Also like Buck2, its written in Rust.
When I was at Lyft we went through a laborious build system migration, including on Android going from Gradle to Buck(1) to Bazel, which at one point involved a full shim that allowed single build files to work on either Buck or Bazel. The idea of being able to keep the same build definitions but swap out engines is pretty appealing.
Julio actually calls for yet-another Bazel replacement as well, this one more focused on the small project/local build case: I can definitely see the appeal there!
The time for these next-generation Bazel-compatible build systems is now. Google has spent the last 10 years Starlark-ifying Bazel, making the core execution engine replaceable. We are reaching a point where the vast majority of the build logic can be written in Starlark as Bonanza proves, and thus we should be able to have different build tools that implement the same build system for different use cases