Hey everyone! 👋🏻 I've a question for the team about the Pulumi SDK design. Given a Pulumi

Output

appears to be conceptually the same as a Future, could the Pulumi

Output

type (in theory) extend the language's Future equivalent, rather than operating independent of it? In the Node SDK, for example, it would be really nice to be able to

await

an

Output<T>

like I would a

Promise<T>

. I'm also curious about the design decision to use constructors as the provisioning call rather than e.g. a method on the object. As it's all more for my curiosity than anything, I thought I'd ask here rather than on GitHub ☺️

GitHub would be better for this question as the design team generally moderate the github issues, we're generally here for tech support 🙂

I know there is an existing issue exploring exposing the functionality required to

await

and

Output<T>

. Currently there exists some variation of

Output<T>.GetValueAsync

that you can await in most of the SDK implementations but it may not be exposed the way you would like. Some discussion here: https://github.com/pulumi/pulumi/issues/6374 As for being declarative versus functional, I agree that in some scenarios the latter would be better than the former. For instance if your code looked like:

var stack = new Stack();
var bucket = new Aws.S3.Bucket(...);
stack.Add(bucket);

Would solve a fair amount of internal problems related to statically detecting the declared bucket implicitly. But obviously has trade-offs of its own and is a large architectural change so 🤷‍♂️