https://pulumi.com logo
Title
r

ripe-russia-4239

06/01/2021, 3:21 PM
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 ☺️
b

billowy-army-68599

06/01/2021, 3:22 PM
GitHub would be better for this question as the design team generally moderate the github issues, we're generally here for tech support πŸ™‚
πŸ€¦β€β™‚οΈπŸ» 1
b

bored-oyster-3147

06/01/2021, 3:48 PM
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 πŸ€·β€β™‚οΈ