Thinking through the implications of `

[rapid canyon]

Briefly discussed it here: https://github.com/dagger/dagger/pull/6370

I do like the explicit Optional type (though I'm more in favor of the Rust naming convention: Some/None, etc)

But @sterile nova had a few good points in that issue.

I removed all Opt usages from my code and it works.

The fact is, optional types work best with functional style APIs and programming, otherwise you just need to write a lot of unwrapping code (see points by Erik mentioned above).

(BTW I wrote a little something to work with optional values: https://github.com/sagikazarmark/go-option)

[empty tree]

Yeah unfortunately this just feels like an intrinsic rough edge - no amount of tidying up on our end is going to fix the underlying problem: go does not really want you to do optionals or default values like this.

Default values won't be applied. Is that a problem?
There's not really a solution to this sadly - even with the Optional type you can't make this. I did consider the idea of a Default type, but this would require something like Rust's const generics, and as far as I could tell this isn't really anywhere on a Go roadmap.

Optional status won't be respected
Default also won't be respected - it feels relatively consistent that for go, these don't "properly" work. If you want a language that has those features, you can always write your zenith module in a language with stronger guarantees around this (yay, multiple sdks 🎉).

Thankfully, there's a long(er) term plan to work around this - we want to add module Self calls, and serve modules their own API, and have code-gened methods for themselves. This is a bit technically complex (hence not done yet) to do but @sterile nova has done a lot of the prep work to make it possible. This way, you can do intra-module calls by going through the engine, which can do all of the magic optional/default/interface magic/etc.

---

As an aside, I did have the idea that we could entirely change how our calling convention for dagger works - and only allow using the WithOpt pattern. This means we could potentially enforce optionals/defaults in Go, but this is so much more ridiculously verbose (and we can't codegen away a lot of it sadly), that I'm tempted to just say no to it.

One of the benefits though of Module SDKs though is that if someone has a really cool idea for how to do this completely differently, they could build their own go SDK and try some of this out.

[ionic grove]

+1 to Self calls - it would make intra-module calls look much nicer in the new TUI, since you'd actually see the encapsulation preserved

[ionic grove]

Cross-referencing where that came up in hopes of more TUI feedback: #1203178812729458708 message

[vernal ravine]

Yeah I just assumed self calls were technically impossible from past conversations. But obviously if we can get that in the future, it's ideal.

Thanks for the details!

[midnight frost]

It's possible via raw query, just missing the codegen roundabout.

[rapid canyon]

Yeah unfortunately this just feels like an intrinsic rough edge - no amount of tidying up on our end is going to fix the underlying problem: go does not really want you to do optionals or default values like this.

Christmas wish: Go and Rust should have a baby 😄

[rapid canyon]

OMG, that scared me

[vernal ravine]

merry christmas