Works fine for us for glueing a bunch of CI steps together which would've been a pile of bash otherwise. Works well with depot.dev caches. We don't use it for anything AI either.

No, it's code based CI/CD not a build system.

I'd say it's somewhere in between. Sure it's marketed in the CI space, but to me the selling point of Dagger is not so much "write your GitHub workflows/GitLab CI in JavaScript" but "local exec, sandboxing, determinism, and fine-grained (remote) caching for mere mortals". So comparing it to Bazel/Buck2 is reasonable.

I wouldn't because build systems like Bazel are declarative and dagger is imperative. I accidentally created a build system in dagger and saw the difference; the code based way was highly branched, and thus unwieldy. I think you would want to call bazel from dagger to handle the build step.

Dagger uses BuildKit. all your “imperative” code does it assemble a graph that’s gonna be executed by BuildKit in dependency order.

But that dependency order is usually just one big blob of ”COPY src/ . + RUN make”, within that block you have none of the benefits. Bazel/Buck has much finer awareness down to every individual file.

Out of curiosity, would it be feasible to take a big cmake project and generate thousands of compile rules into dagger and use it as a substitute for make with sandboxing? I’ve never seen builkit used with such many nodes, how would it fare?

Dagger is a declarative DAG engine. So, yes, you can do that.

There is an overhead per container launched so it would probably not be worth it.

Yes, but that does not help you build declaratively in dagger, does it? I would like to see an example of how to do so, if you have one.

Its not as fine grained as bazel/buck. That doesnt necessarily matter.

Yeah, it's more like a .NET Aspire

I use it to do builds in our monorepo. We got onboard before the LLM trash features. The base design is ok but there's things I'd do different today if I knew the build stuff would fade away for the LLM push.