using dagger go sdk while reducing overall complexity over just writing non-dagger Go ... | Dagger | Page 1

void island Nov 6, 2024, 9:43 PM

#

So one thing I recall being mentioned was that dagger composability would mean I could output say json from one command then consume it with another func to chain actions.

My test case makes it feel a bit more complicated and difficult when I could probably knock this out with a simple mage task or even a main.go file.

Not sure if I'm missing something, and maybe a few examples might make help it make more sense.

Think of this as me trying to provide an cli/automation command.
Mage/native go is straight forward (as long as Go is there), but with dagger it feels more complicated than just native Go.

One thing I'd be interesting in seeing is you have a "before / after" from something that was automation oriented and not complex pipelines and how dagger's Go was actually simpler than the original Go due to some benefits like optional parameters, composability of functions or something?

I am still plugging away but I want to ensure I'm demonstrating the benefit and not just over complicating something when I do some presentations/demos at work later on this.

void island Nov 6, 2024, 10:05 PM

#

and if you have someone that's interested, i could jump on a short session and sorta share what I'm doing and get some feedback if it's of use. cheers

void island Nov 20, 2024, 5:29 PM

#

Bump so it's not lost. I think this might have been missed to company event that happened at same time.

heady shuttle Nov 20, 2024, 6:12 PM

#

I'd say it depends on what you're doing. My dagger code has heavy use of dag.Container, dag.Directory and all the functions that come with them. Writing this in go would be rather cumbersome, to say the least. On the other hand if you're just writing a cli tool to do basic things in stdlib implementations (read/write files, take input, etc.), dagger might be a complexity add without much value.

I didn't really have to "sell" dagger as I know many do (small team, I have a lot of decision making power in my area of expertise), but looking retroactively the amount of yaml engineering I've avoided, the speed with which I've been able to expand my pipeline operations, and the consistency of the platform over time have all been huge timesavers for me and my team.

void island Nov 21, 2024, 12:11 AM

#

yeah it's cumbersome right now and a lot more cognitive load than just throwing some Go together.

My hope was though that the slower time would simplify invoking common automation that's not pure build/release that needs to do local stuff because not everyone uses Go and therefore I always run into friction with environment differences. If I'm gonna wrap in docker might as well at that point use dagger too, but it's a lot more initially to work through because of the isolation model.

Good points, so thanks for chiming in 🙂

#using dagger go sdk while reducing overall complexity over just writing non-dagger Go ...