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.
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.