Better typing for Go SDK

[johanbrandhorst]

Hi!

I'm really excited by this project, but I was immediately disappointed by the SDK types. Here's the first one I found:

type GetAmiArgs struct {
	// Limit search to users with *explicit* launch permission on
	// the image. Valid items are the numeric account ID or `self`.
	ExecutableUsers interface{}
	// One or more name/value pairs to filter off of. There are
	// several valid keys, for a full reference, check out
	// [describe-images in the AWS CLI reference][1].
	Filters interface{}
	// If more than one result is returned, use the most
	// recent AMI.
	MostRecent interface{}
	// A regex string to apply to the AMI list returned
	// by AWS. This allows more advanced filtering not supported from the AWS API. This
	// filtering is done locally on what AWS returns, and could have a performance
	// impact if the result is large. It is recommended to combine this with other
	// options to narrow down the list AWS returns.
	NameRegex interface{}
	// Limit search to specific AMI owners. Valid items are the numeric
	// account ID, `amazon`, or `self`.
	Owners interface{}
	Tags interface{}
}

I understand this was probably a compromise to get things ready for GA, but I'd like this issue to track the work on typing this stuff up, otherwise it's little better than the JS SDK (:scream:).

Thanks

[joeduffy]

@johanbrandhorst thank you for filing this. As the guy who put this together, I can't agree more.

One of the challenges we have, which I would love feedback on since I ran out of ideas, is that it's tough to type these things. I'm not sure if you noticed all the specialized *XOutput types, which more strongly types resource properties after being provisioned. The challenge we have is that we want to permit, say, string and *StringOutput for string-based input properties. In TypeScript we use union types. In Go, I'd have liked to have an idiomatic discriminated union that can accept either, but it wasn't clear the best way to do this that enabled idiomatic calling code (without casts).

/cc @pgavlin also, since he is our resident Go idioms guy.

[lukehoban]

I wonder if we should consider functions like pulumi.String(str) which return a StringOutput and then have all these inputs accept StringOutput. (The name of StringOutput may need to change for this to feel right). These "Output"s wouldn't carry any dependencies.

This would be a lot like aws.String and friends in the AWS SDK as a way to lift values into the reference types need in that API. In our case, we would require lifting everything manually into the Output space.

It would be rather verbose, but in a way that is fairly idiomatic for Go.

[johanbrandhorst]

@joeduffy @lukehoban thanks for your replies! I'm personally not a huge fan of the stuff the AWS SDK does (afaik it's just a helper for creating a pointer to a string literal). For discriminated unions I think the best you can do at the moment is using an unexported interface like the Go protobuf implementation:

type stringOption interface {
    func isStringOption()
}

type StringOutput struct {
    ...
}

func ( _ StringOutput) isStringOption() {}

Unfortunately this does not work with native strings of course... so you'd still need a pulumi.String(in string) stringOption. I suppose then you could have pulumi.CustomStringType.StringOutput() StringOutput for converting between output and inputs. That might be the best option after all.

[swgillespie]

Go support is out of scope for M21.

[lukehoban]

Part of pulumi/pulumi#3506?