What's New in Bazel 6.0

I think that this is a problem with branding which unfortunately Bazel is using. I think remote caching and remote exec are not the best features that Bazel has to offer.

First to answer your question: distcc and ccache are great but they offer a limited amount of flexibility in what can be distributed. Bazel's approach is generalized and operates on this basic set of steps:

1. Configure a "target" (define inputs and outputs) 2. Load the deps for the target into a sandbox. 3. Run a command in that sandbox. 4. Copy the outputs out of the sandbox.

With this approach you can execute anything as it's just running a shell program with some args. For example: lets say you are building a game and you have a process where you take raw models from your designers and compress them into an efficient storage format. This can be a `genrule` in your BUILD file and instantly get rerun whenever anyone submits a new change to the models. Now that it's been run in CI all of your devs will not need to rebuild this on their machines. That's the goal. Basically: it is more generic than caching a specific language's data. You can cache everything.

My favorite part of Bazel is the layer of abstraction. Rather than thinking of build steps, what args to gcc are getting passed, etc you are thinking about libraries, binaries, tests, and other artifacts.

Also, this abstraction of inputs and outputs makes it so it's easy to eventually build higher level abstractions. For example, this should be possible at some point:

    cc_binary(
      name = "foobar",
      srcs = [...],
      hdrs = ["foobar.h"]
    )

    # Automatically generates jni binding
    # for a C++ library just by reading the
    # header file and binding all types.
    java_cc_binding(
      name = "foobar_java",
      deps = [":foobar"],
      namespace = "::foobar", 
      generate_class = "foobar.FoobarBinding",
    )

I think the framework to allow others to build on this abstraction and make things take less effort overall is the huge value add.

I find it interesting that Bazel and Nix don't seem to complement each other as much as I'd think given that they're both 'high effort, high reward tools which deal with hermetic building'.

They certainly both suffer from issues related to upstream packages doing their own thing.

> They also suffer from another problem which is that most people don't care as much as you or I do. :) ...

I use Nix. I haven't use Bazel.

I think Nix is wonderful for enthusiasts. It takes some time to learn. However, Nix is excellent at dealing with packages. And developers often do things which involve packages. -- e.g. Nix is good for declaring a shell with programs that can be made available.

Having used both Bazel and Nix, I agree they suffer here but with a slightly different take: They suffer because they must reinvent the wheel and provide a new API to mimic the upstream package managers. They're in a constant race to keep pace with best practices outside of their community - and patch their APIs accordingly which become "dirty mirrors", only partially reflecting the intent and functionality of upstream tooling.

But that's kind of the point - they apparently need to take over and constrain the system to fully understand the dependency tree.

I wish there was a Bazel/Nix/Guix build tool that had some barrier between the dependency tree and the developer tools that one uses daily. When I'm building the system as a whole, I don't want to think about cargo vs npm. But when I'm writing code for a given component, the native tooling is the correct abstraction. Is it even theoretically possible to resolve those two ideas without introducing another glue language?