Plus, and maybe this is actually by design, it lets a more common system "generate" the various Args for different things, irrespective of the underlying language dialect chosen for a particular set of resources managed with pulumi. E.g. mix and matching typescript, golang, python etc, and using a common return map for generating allthethings

I'd say it's mainly a design thing. The main goal of Args objects is to provide somewhat reasonable IDE experience so as a developer you do not need to look into the documentation every time you are creating a resource. The support in pulumi is not great (yet) I'd recommend trying out the feel of AWS CDK to understand. All of the above (should) saves you a lot of time figuring out what arguments does the resource take so you do not need to remember. This ability goes away with python

dicts

because IDEs are not able to introspect the data structures to give you hints. In JS/TS you have Objects that only look like a python

dict

. So in JS/TS

Obj = { prop: 'value' }

in python is

class Obj:
   def __init__(self, prop):
         self.prop = prop

Obj(prop='value')

In this case IDEs can tell you that

Obj

expects

prop

. but if your object accepts the only

dict

class Obj:
   def __init__(self, arg_dict):
         self.prop = arg_dict['prop']

Obj(arg_dict={"prop": 'value'})

There isn't a way for IDE to tell you what shape or keys are required. So this leads to

KeyError

on execution time

Obj(arg_dict={"not_expected": 'value'})

- which is expensive due to mental overhead and developer time. That's why TS feels a little bit more natural

It is possible with TypedDict. See https://github.com/pulumi/pulumi/issues/3771 It might be worth it to reopen a discussion again.

Aye.. yeah. I won't disagree. I decided to stay with the

*Args()

constructor convention since it does provide that introspection which can be valuable to developers who are new to things, especially k8s spec, and don't quite understand what the dict form should look like etc.