The most magical thing about Pulumi, however, is that you get all the same predictability guarantees of an infrastructure as code tool, while still embracing general purpose languages.

spot on from the blog post. when I spoke about pulumi with colleagues first reaction was that "normal programming language is not declarative" , and therefore it is dangerous to use

I’ve been thinking about this aspect a lot myself. I think as an industry we’ve over-emphasized “declarative” as a silver bullet, when in fact it just isn’t well suited for a lot of situations. If you look at the Kubernetes space, there are reems of YAML and configuration files. So much so that even more complex wrappers such as Ksonnet and Cue are built on top of it — trying to simplify the experience, while still being 100% declarative. But at the end of the day, what is the problem you are trying to solve? If your goal is to make it easier to understand how you are setting up your cloud infrastructure, then if you are setting up 100 EC2 VMs, having a “for loop” that executes 100 iterations is sufficiently clear. Of course you can write super-complicated, difficult-to-maintain code using a real programming language. But that’s why we have code reviews, type checking, linters, style guides, etc. It’s easy to make code readable and understandable. When you are using a purely declarative model, you don’t have much flexibility.

Chris said it eloquently, but I think the short rebuttal is, "Declarative doesn't scale well or flat our work in certain cases" The solution in the past has been jamming stuff on top of the declarative language; you end up with amalgamations of the worst traits of both models mixed up and on top of one another. Then there's the intended audience. If someone is really comfortable in modern programming languages and has to write your cloud infrastructure code, and they are not so comfortable with terraform or cloud formation speak, just give them the tool they are most experienced and comfortable with. You will get better results. It's a bit of a fallacy to appeal to Fear to govern policy: imperative languages are dangerous, we should not use them. There's no proof that they are "dangerous" and even if you could make that assertion, discarding a powerful tool out of fear is not wise.

i'd be pretty surprised if most orgs aren't running a collection of bash scripts on top of their helm/terraform code anyway.