6 ms·

This is a pretty interesting project, a low setup distributed build cluster is cool. That said I find the arguments against Bazel pretty weak. Yes with a dist

This is a pretty interesting project, a low setup distributed build cluster is cool. That said I find the arguments against Bazel pretty weak. Yes with a distcc model you can scale out the compilation stage of C++ project quickly, but what about the test execution, linking, ProtoBuf code generation, or caching? In either case, Bazel or Llama you have to make your build system aware of how these actions work in some way in order to distribute or cache them. The difference is with Bazel you also gain a suite of solutions for large software projects like container creation, target visibility control, isolation, dependency fetching, and build graph analysis. Also with the larger community behind Bazel adopting it for a large project is getting easier over time.

nsm 5y ago
The author has plenty of experience with Bazel, as Sorbet, the Ruby type checker they helped create uses Bazel. I agree that Bazel is almost always the right solution beyond a certain scale or multi-language builds. The unfortunate reality is that open source developers have decided that they don't want the state of the art because "it's written in Java and is like a 50mb binary". Yes, I know there are certain things about Bazel that don't fit certain open source projects, like it may not be easy to bootstrap a build environment for OSes that want everything to be built from scratch, or want to support 10 different architectures, and I agree that Bazel may not make sense there. At the same time, if you see comments from both HN and on the internet, "it's in Java" is often how FOSS projects are making these decisions :( I'll always be bitter about this. In particular I feel like Cargo was new enough that Bazel existed and if they had at least built a Bazel compatible tool in Rust (so use Starlark etc.) it would have been very much in line with the Rust ethos of safety and speed.

nsm 5y ago

The author has plenty of experience with Bazel, as Sorbet, the Ruby type checker they helped create uses Bazel. I agree that Bazel is almost always the right solution beyond a certain scale or multi-language builds. The unfortunate reality is that open source developers have decided that they don't want the state of the art because "it's written in Java and is like a 50mb binary". Yes, I know there are certain things about Bazel that don't fit certain open source projects, like it may not be easy to bootstrap a build environment for OSes that want everything to be built from scratch, or want to support 10 different architectures, and I agree that Bazel may not make sense there. At the same time, if you see comments from both HN and on the internet, "it's in Java" is often how FOSS projects are making these decisions :( I'll always be bitter about this. In particular I feel like Cargo was new enough that Bazel existed and if they had at least built a Bazel compatible tool in Rust (so use Starlark etc.) it would have been very much in line with the Rust ethos of safety and speed.