What would be an argument for one that

[primal gull]

Heavily depends on the environment where Bazel is used in, because a huge advantage of Bazel is that it can use native environments, whereas everything in Dagger runs in containers...and not everything can be containerized.

So if something can't be containerized that you use, introducing Dagger doesn't really make sense. (In any kind of argument, making sure I'm comparing apples to apples is kind of the first step, so I like to clear that upfront).

Based on my personal experience:

Language: Starlark is a python like language, but it's severly limited compared to Python/Go/TypeScript. Also, in order to implement any kind of high level functionality in Bazel, you need to become a rocket scientist. With Dagger, it's just plain old code with a few (arguably) simpler concepts.

Environment: if the native environment isn't important, containerization can make portability much easier.

Support: although Bazel is widely used (I guess), it's still not a very common tool. Mostly due to its complexity. Which means it's gonna be harder to find support for it compared to a fancy new tool that everyone wants to use.

Architecture: Bazel forces a particular architecture on how you think about builds. Everything is an artifact, each artifact may depend on another artifact, etc. Conceptually, it makes a lot of sense (NixOS kinda works the same way).

However, to achieve that, Bazel needs to "hack" a lot of native language tooling. I'm mostly familiar with Go, so this may not apply to a "lot" of languages, but in Go's case, it definitely does a lot of hacks under the hood. If you don't mind getting your hands dirty when you occasionally need to debug something, it's fine, otherwise, you may find yourself in a lot of deep rabbit holes. Dagger on the other hand doesn't do any of that.

(One of the reasons why Bazel does these things is extreme caching which is a huge advantage, but you can get very similar results with Dagger (or containers in general). Using Go as an example again: Go has build caching builtin that works well with Dagger's cache volume support and kinda makes Bazel's approach unnecessary in a purely Go project. Cross-language dependencies is a different beast though)

tl;dr if you don't have a lot of experience with Bazel and you don't have any requirements that Dagger cannot fulfill, the learning curve and the upfront cost of introducing (and maybe even maintaining) Bazel is much higher than the cost of Dagger.

"/chatgpt turn this into a blog post" 😄

[wheat badge]

Yea so the jist is, that we have new lead that started whom has a lot of experience with Bazel, and i have been using Dagger.IO for smaller things, so i was not sure how to approach and show some of the benefits with Dagger. One i assume is like it uses General purpose language, where as Bazel and like Nix uses their own DSL

[glacial gull]

Another reason - from my memory, bazel also doesn't really provide much in the way of arbitrary user-facing scripts.
Part of the power of dagger is you can use it to build, unit test, integration test, statically analyze, deploy, etc: all from one command line that can be kept very minimal.

You shouldn't need layers of scripts to be able to call dagger (and we're continuing to improve that for the cases where you still need something like that today).

[glacial gull]

honestly, do it 😄

[primal gull]

Uh, it takes a lot of courage to convince someone up in the foodchain. I've been on both sides, so I know perfectly well how hard it is. 😄

Technical arguments aside, this is more of a management question IMO.

• Is there a need for big changes?
• Does your team have the expertise to learn Bazel or Dagger?
• Do you have the budget to run a PoC tho showcase both?
• Does your team have the authority to choose or is it going to be decided by your lead?

Tech people are sometimes set in their ways, especially when they believe something, rather then being convinced by arguments.

So my advice: try to be reasonable, but don't die on a hill you don't want to. Try to figure out what are the requirements for this decision. Try to compare Bazel and Dagger within those parameters. It also doesn't hurt if you have your team behind you, but make sure your lead doesn't feel like you are turning people against them.

Make sure you put good arguments on the table, but commit to the decision afterwards. If it turns out to be a bad decision, whoever made that decision will have to be responsible.

[hybrid vortex]

Here's my recommendation: don't go against the core tool (Bazel; Nix; Gradle..) directly. Instead focus on being a complement. Those tools typically are used heavily for the core of the project, and evangelized heavily by a core team. But there's always a long tail of software, and people, that are not able to use the core tool for everything. Dagger is the perfect complement because it can integrate the core tool, and the long tail tools, in a cohesive whole.

• If your org uses Bazel, there are people in the org that love using it, and leaders who introduced it that are emotionally and politically invested. You should be careful that they don't see Dagger as a threat. That means emphasizing that Dagger adapts to your stack, not the other way around. Bazel fans will continue to use Bazel.

• At the same time, if your org uses Bazel, there are lots of people who are fed up with it. They need to integrate with the Bazel core, but they are being forced to use Bazel for everything and it's hurting their productivity. For them, Dagger is a godsend. Find who they are, and convert at least one of them to a Dagger champion. As in, help them solve a hair on fire problem with Dagger.

[hollow gust]

given mark's talking about his experience with bazel + go, i think it's worth mentioning that go has one of the nicest and most mature bazel implementations out there (C++ is probably better, and maybe java) – but with other languages, building using bazel often means you lose out on tooling from the rest of the languages ecosystem.

i joined dagger from a bazel shop, where we had a team of folks (in reality mostly one guy) supporting a large set of bazel customizations to build, test, configure, and deploy a combination of kotlin, elixir, go, python, node, helm, and jsonnet files in a large monorepo. bazel is definitely highly customizable, but I think if dagger had existed when that shop started using bazel, we would've been better off going the dagger route and using it to drive language-ecosystem-native "build" tools like gradle, mix, pnpm, uv... we chose bazel back then because it was the only thing that gave us a unified platform to chain multi-language incremental builds into deploys.

put another way and echoing solomon, if you've got one language where bazel is the right choice, dagger gives you the flexibility to use bazel to build that one language without forcing bazel to be the choice for every language. i can tell you building elixir and kotlin with bazel is not a fun time.

operationally, bazel experts are insanely difficult to hire (although your TL is one apparently, and probably has a network, so maybe this problem is less acute for y'all) and meanwhile there's a ton to learn and implement in order to get to the promised land of highly-isolated incremental hermetic builds. dagger, imo, is far more amicable to folks with experience with the language-ecosystem tools contributing to their own builds.

[hybrid vortex]

By the way, if I may invite @vague rivet here - he had a relevant experience but in a Gradle shop. I think a lot of the same dynamic applied than for a Bazel shop

[hollow gust]

pcre(two conn?ors, one (bazel|dagger) discussion)

[vague rivet]

Thanks for roping me in. I think one thing about bazel (and gradle as well to some extent) is that these technologies are also trying to solve some of the same issues that Dagger is trying to solve. Notably a robust caching framework (each software has their own constructs for this, bazel has its way of handling caching, common interfaces for developers to interact with as they pass build components around, and an ecosystem of plugin-like functionalities to modularize building blocks for CI. The main limitation I found with gradle, beyond its inherent complexity, are the following:

1. It's not container native
2. The non-java ecosystem of tooling around doing things like building OCI images and in general just doing anything non JVM that you might want to do in CI caused a lot of pain due to the simple lack of developer tooling in the ecosystem. Gradle does let you do non-java native things like build OCI images, do python/go/whatever stuff via plugins, it's just not super good at it, and working with the gradle plugin framework is quite painful. There are also very few developers actually building plugins for gradle. This is one thing Dagger offers in this regard - nicer, more native interfaces and ecosystem tooling to build your ci abstractions around, absent of actually building your software

So in gradle's case, how we approached this from a design perspective is we just said "anything involving building java/kotlin/scala/jvmwhatever is handled by Gradle. Anything else is handled by Dagger". This basically involved staging appropriate files into OCI containers, hooking into existing gradle caching constructs and mapping them to Dagger constructs like dagger's caching api's, and then just running the typical gradle build commands inside containers to invoke the builds, but using Dagger API's to handle everything else

so it seems like, rereading your last comment, that you're basically looking at something very similar - a framework where bazel is invoked inside a container.

One thing about gradle and bazel is that they are both task runners as well. One thing to watch out for is designing a common interface for your engineers so they only have to worry about one entrypoint to invoke builds. In this way Dagger can also help - you have a cli tool that is flexible enough to handle language agnostic tooling commands - in our implementation we don't expect end users to directly invoke gradle, but rather the dagger command that invokes gradle. This is because if we want them to jump into a new repo the interface should remain the same (build, test, deploy/publish) regardless of the underlying software ecosystem

in general I've been pushing engineers in our organization towards container native tooling approaches, to get away from "works on my machine" problem. This can sometimes be difficult when your existing SDLC involves invoking commands locally. One of the difficulties of Dagger adoption is showing people why the extra thought and overhead of building and deploying in containers is worth the tradeoff. Dagger is really great at showing how this works from a caching perspective, but you still have to solve all sorts of problems about how to stage secrets into the container, how to manage environment variables, how you publish your images, etc. But if you can communicate the core philosophy and the reasoning behidn it well, usually peopel are able to see the light fairly quickly

[hollow gust]

in general I've been pushing engineers in our organization towards container native tooling approaches, to get away from "works on my machine" problem
my old team really struggled with squaring the circle between container-native tooling approaches vs featureful inner-loop dev tooling, like running single tests by line-proximity from an IDE, attaching debuggers, or running language servers to plug into vscode. those are all really good places to make comparisons between bazel and dagger+language-native-tooling. if you go blindly into either one, it's very easy to incidentally wall off a lot of productivity tools from your product devs... you wanna walk into those tradeoffs knowingly bc eventually some platform enges are gonna need to fill the gaps

[hollow gust]

tbh the dagger engine itself currently struggles a bit with the debuggers and line-proximity test running

[vague rivet]

yeah, I think from the DevEx perspective being well integrated with a local debugger toolchain is huge. When a developer comes in and says "I want to wire up my intellij/vscode/whateverIDE" for step through and doing so is not straightforward, it's an immediate turnoff from the developer on that toolchain. It's definitely worth focusing on when thinking about developer adoption of toolchain

that is usually the main reason i see devs want to cling on to their local dev toolchain outside of a container, that "critical tool XYZ does not work out of the box for me and there is no instructions to wire it in"

(the other one being, container startup is sluggish and take too long, which is a problem that improves with every Dagger release)