To be clear, Bazel focuses on correctness because it's essential to acheiving performance at scale.

If you don't have correct caching of intermediate build artifacts, a system can't handle the compile and test requirements of large codebases.

that +1000

> Does it enforce hermecity or deterministic builds or give me tools to accomplish it?

I wouldn't say moon is hermetic, nor are we trying to be. We don't use the sandbox approach for tasks, and run against the original files. For the languages we support, this works best.

As for deterministic, we try to be. We have a "toolchain" where we download languages/tools in the background, and run tasks using these tools. This ensures, at minimum, that the same version/variant of a tool is used across machines.

> In the same vein as those questions how does caching work?

It's content based. We also hash other kinds of inputs depending on the language that is running.

> If the configuration language is YAML how am I expected to implement new behavior? (and other questions)

Our focus right now is on non-compiled languages, primarily web languages, where custom behavior (like Starlark) is not necessary. In the future, this may change.

How do you target large codebases then? The whole point of hermeticity is to allow you to reliably not rebuild and test everything on every commit which is the issue most large codebases have.

Also a bit disingenuous to describe it as language agnostic if it only really works with non-compiled languages.

moon will only run on affected projects, so you're not building/testing everything. This is done through a combination of hashing + caching.

It's also language agnostic because you can technically run anything through moon, but support may vary. https://moonrepo.dev/docs/faq#can-we-run-other-languages

> moon will only run on affected projects, so you're not building/testing everything

But you can only reliably know what is affected through hermeticity.

> It's also language agnostic because you can technically run anything through moon

That's just calling out to another build system though. I don't think it really counts.

Bazel as a taskrunner/build system is to most monorepos as a Pile Driver [1] is to a floorboard nail. It will do everything but it's massive overkill. We are agreed that Nx doesn't measure up, but I wouldn't compare it to Bazel.

[1] https://en.wikipedia.org/wiki/Pile_driver

Fair point. I treated the product as a build system and it just doesn't look right. However it makes perfect sense if it advertised itself as a "task runner".

When you start having 100 applications (a typical game may have that amount), even if only 10 of them are thorouhgly tested, you end up needing that pile driver, or you end up compiling all 100 of these on every presubmit. Just sayin.

I think it's hilarious to say bazel focuses on correctness when it doesn't ship with any hermetic toolchains by default. Properly setting up hermetic toolchains is poorly documented and left as an exercise to the reader.

I say this as someone who wants to love bazel... I just can't understand why it picks up impure toolchains from the system at all.

Bazel plus nix.

This feels like the way, but comes with the huge caveat that it doesn't work with bazel remote execution (unless you can rig up something to sync your nix store to every remote builder).

I haven't used it personally, but the Nix manual mentions support for dealing with Nix stores in distributed builds https://nixos.org/manual/nix/unstable/advanced-topics/distri...

You have to remember that it was the very first system to even attempt hermetic & deterministic builds.

Combine that with the fact that C++ toolchains at least make assumptions all over the place about being spewed over `/usr`... I think they just bowed out to practicality at that point.

You're definitely right it should use hermetic toolchains. I'm curious which other Bazel-like build system does that by default?

I wouldn't call it a bazel-like, per-se, but Nix seems to have tamed C++.

I don't think it was easy, though.

As I understand it Nix can do hermeticity on a project level, but not on a build step level like you would need for actual development. So it's good for building OSes. Not for building software products.

I agree they target slightly different use cases, but I don't think that's a good excuse for why bazel can't be more hermetic out of the box.

> You have to remember that it was the very first system to even attempt hermetic & deterministic builds.

Given its Google-internal predecessors, it’s not clear how priority should be established (the general guideline in science is that non-public is not science, but that might not be what we care about here). The public Bazel, though, is from 2015, while the first releases of Nix date back all the way to 2004[1] and the thesis is from 2006.

Now Nix is not really at its best if used as a general-purpose build system, but it certainly has and uses hermetic toolchains.

[1] https://releases.nixos.org/nix/nix-0.5/manual/manual.html

Yeah it can be done but it's painful. In general the Bazel rules are lower quality than Bazel itself - and rules_python is one of the better ones!

I agree this is one of the biggest weak points of Bazel. It lacks a distribution that provides all these goodies out of the box, with maintained and documented workflows. Setting up hermetic builds and remote caches, builds & execution requires a whole team of experts right now.