Live data from Hacker News

Dagger: Define software delivery workflows and dev environments

dagger.io

61–70 of 78 posts

Re: Dagger: Define software delivery workflows and dev environments

#61
post #60
post #10

Dagger was something I looked into two or so years ago before they got consumed by the LLM and AI agent hype, and while the promise of being able to run the exact CI workflows locally seemed excellent, it seemed that there's basically no way be a Dagger user without buying into their Dagger Cloud product. I ended up opting for CUE and GitHub Actions, and I'm glad I did as it made everything much, much simpler.

Do you have examples of your CUE and Github Actions setup?

I see someone else asked below:

https://news.ycombinator.com/item?id=46262846

Re: Dagger: Define software delivery workflows and dev environments

#62
post #46
post #43

Earlier quoted context omitted.

dagger was originally CUE-based, but there was not enough demand so it was dropped. https://dagger.io/blog/ending-cue-support

> If you’ve been active in the Dagger community, this news will come as no surprise. Since we released multi-language support, we have seen a steep decline in usage of our original CUE configuration syntax, and have made it clear that feature parity with newer SDKs would not be a priority. That is, of course, a self-fulfilling prophecy (or, perhaps, a self-inflicted wound). As soon as Dagger's "multi-language support…

Dagger founder here. We moved away from CUE because the number one complaint from our early users was having to learn CUE. The number two complaint was bugs in the language that we diligently escalated upstream, but would never get fixed, including crippling memory leaks.

We shipped multi-language support because we had no choice. It was a major engineering effort that we hadn't originally planned for, but it was painfully obvious that remaining a CUE-only platform was suicide.

Re: Dagger: Define software delivery workflows and dev environments

#63
As someone that has used Dagger a lot (a previous daggernaut / ambassador dropped off after LLMs was announced, and was changing jobs at the time. implemented it at a previous company across 95% of services, built the rust sdk) the approach was and is amazing for building complex build chains.

It serves a place where a dockerfile is not enough, and CI workflows are too difficult to debug or reason about.

I do have some current problems with it though:

1. I don't care at all about the LLM agent workflows, I get that it is possible, but the same people that chose dagger for what it was, is not the same audience that runs agents like that. I can't choose dagger currently, because I don't know if they align with my interests as an engineer solving a specific problems for where I work (delivering software, not running agents).

2. I advocated for modules before it was a thing, but I never implemented it. It is too much magic, I want to write code, not a DSL that looks like code, dagger is already special in that regard, to modules takes it a step too far. You can't find the code in their docs anymore, but dagger can be written with just a .go, .py or .rs file. Simply take in dagger as a dependency and build your workflow.

3. Too complex to operate, dagger doesn't have runners currently, and it is difficult to run a setup in production for CI yourself, without running it in the actions themselves, which can be disastrous for build times, as dagger often leads you into using quite a few images, so having a cache is a must.

Dagger needs to choose and execute; not having runners, even when we we're willing to throw money at them was a mistake IMO. Love the tool, the team, the vision but it is too distracted, magical and impatient to pick up at the moment.

Re: Dagger: Define software delivery workflows and dev environments

#64
post #41
post #40

I thought Dagger had/has a lot of potential to be "AWS-CDK for CI pipelines". I.e. declaratively setup a web of CI / deployment tasks, based on docker, with a code-first DSL, instead of the morass of copy-pasted (and yes orbs) CircleCI yaml files we have strewn about our internals repos. But their DSL for defining your pipelines is ... golang? Like who would pick golang as "a friendly language for setting up configs"…

They have SDKs in many languages, not just Go. I use the python one. And they use code, not a DSL.

Right, my point is that this:

https://docs.dagger.io/cookbook/services?sdk=typescript

Still looks like "a circa-2000s Java builder API" and doesn't look like pleasant / declarative / idiomatic TypeScript, which is what aws-cdk pulled off.

Genuinely impressively (imo), aws-cdk intermixes "it's declarative" (you're setting up your desired state) but also "it's code" (you can use all the usual abstractions) in a way that is pretty great & unique.

Re: Dagger: Define software delivery workflows and dev environments

#65
post #63

As someone that has used Dagger a lot (a previous daggernaut / ambassador dropped off after LLMs was announced, and was changing jobs at the time. implemented it at a previous company across 95% of services, built the rust sdk) the approach was and is amazing for building complex build chains. It serves a place where a dockerfile is not enough, and CI workflows are too difficult to debug or reason about. I do have so…

Hi Kasper, good to see you here! Thank you for the detailed feedback.

1. Yes we got over-excited with the agent runtime use case. We stand by the LLM implementation because we never compromised on the integrity of Dagger's modular design. But our marketing and product priorities were all over the place. We're going to refocus on the original use case: helping you ship software, and more particularly building & testing it.

2. Modules have warts but they are essential. We will continue to improve them, and remain committed to them. Without this feature, you have to write a complete standalone program every time you want to build or test your software. It's too much overhead.

3. Yes you are right. We really thought we could co-exist with CI runners, and get good performance without reinventing the wheel. But for various reasons that turned out to not be the case. So we're going to ship vertically integrated runners, with excellent scalability and performance. DM me if you want early access :)

TLDR: yes we needed to choose and execute. We have, and we are.

Thank you again for the feedback.

Re: Dagger: Define software delivery workflows and dev environments

#66
post #42

Dagger is already a very popular thing -- a DI framework

It's also a type of blade, been around for hundreds of years! /s I've never heard of Dagger the DI framework but I have heard of this Dagger. Names will overlap sometimes and it's not a big deal.

People aren’t going to confuse a physical knife with this.

Android is the most popular operating system on earth. Names can overlap but you shouldn’t choose one where you can’t live up to owning it.

Re: Dagger: Define software delivery workflows and dev environments

#67
post #65
post #63

As someone that has used Dagger a lot (a previous daggernaut / ambassador dropped off after LLMs was announced, and was changing jobs at the time. implemented it at a previous company across 95% of services, built the rust sdk) the approach was and is amazing for building complex build chains. It serves a place where a dockerfile is not enough, and CI workflows are too difficult to debug or reason about. I do have so…

Hi Kasper, good to see you here! Thank you for the detailed feedback. 1. Yes we got over-excited with the agent runtime use case. We stand by the LLM implementation because we never compromised on the integrity of Dagger's modular design. But our marketing and product priorities were all over the place. We're going to refocus on the original use case: helping you ship software, and more particularly building & testin…

Sounds good Solomon I look forward to seeing how it goes in about a year when I am going to tackle our CI again ;)

Best of luck and thx for taking my harsh feedback in strides!

Re: Dagger: Define software delivery workflows and dev environments

#68
post #66

Earlier quoted context omitted.

It's also a type of blade, been around for hundreds of years! /s I've never heard of Dagger the DI framework but I have heard of this Dagger. Names will overlap sometimes and it's not a big deal.

People aren’t going to confuse a physical knife with this. Android is the most popular operating system on earth. Names can overlap but you shouldn’t choose one where you can’t live up to owning it.

People likewise won't confuse a DI framework for Android with a GitHub Actions replacement. Complaints about overlapping names would make sense if both Daggers were DI frameworks or Github Actions replacements, but they're not.

> can’t live up to owning it.

?

Re: Dagger: Define software delivery workflows and dev environments

#69
post #62
post #46

Earlier quoted context omitted.

> If you’ve been active in the Dagger community, this news will come as no surprise. Since we released multi-language support, we have seen a steep decline in usage of our original CUE configuration syntax, and have made it clear that feature parity with newer SDKs would not be a priority. That is, of course, a self-fulfilling prophecy (or, perhaps, a self-inflicted wound). As soon as Dagger's "multi-language support…

Dagger founder here. We moved away from CUE because the number one complaint from our early users was having to learn CUE. The number two complaint was bugs in the language that we diligently escalated upstream, but would never get fixed, including crippling memory leaks. We shipped multi-language support because we had no choice. It was a major engineering effort that we hadn't originally planned for, but it was pai…

Thanks for the response.

I think multi-language support is a great feature, and I understand why you had to go for it. While I'm sure some people likely switched away from CUE once they had the chance because they weren't interested in working with a novel and perhaps quirky DSL, I'm also sure some stopped using the CUE SDK just because it was clear to them that it was being abandoned— I know that because I'm one of them. I'm one of the users who stopped using the CUE SDK after multi-language support came out— and it's not because I preferred using one of those other languages. That's all I'm saying.

Re: Dagger: Define software delivery workflows and dev environments

#70
post #69
post #62

Earlier quoted context omitted.

Dagger founder here. We moved away from CUE because the number one complaint from our early users was having to learn CUE. The number two complaint was bugs in the language that we diligently escalated upstream, but would never get fixed, including crippling memory leaks. We shipped multi-language support because we had no choice. It was a major engineering effort that we hadn't originally planned for, but it was pai…

Thanks for the response. I think multi-language support is a great feature, and I understand why you had to go for it. While I'm sure some people likely switched away from CUE once they had the chance because they weren't interested in working with a novel and perhaps quirky DSL, I'm also sure some stopped using the CUE SDK just because it was clear to them that it was being abandoned— I know that because I'm one of…

I understand. We really did try to port the CUE SDK over to the new APIs, but there were impedance mistmatches that made it difficult to do so without major breaking changes - basically we would have needed to design a new SDK from scratch. We asked for opinions on our discord, and it felt like there weren't enough people interested to justify that kind of effort.

For a while there was activity on the #cue channel about a community SDK (that's how we got PHP, Java, Rust, Elixir and dotnet), but it didn't materialize.

It looks like you were in the minority that would have preferred to continue using the original CUE SDK - I'm sorry that we didn't find a way to continue supporting it.

Post reply on HN