Firstly I don't have any particular faith in them either given their business model appears to be sending them towards a similar path. Secondly, I think encouraging people to write their infra configuration in a general purpose imperative language is quite possibly the worst idea I've ever encountered. As botched an attempt Hashicorp made at designing HCL, they at least had the good sense to make it declarative.
> I think encouraging people to write their infra configuration in a general purpose imperative language is quite possibly the worst idea I've ever encountered.
Good news: Pulumi is also entirely declarative. The model is what matters in this regard, not the syntax used to express it.
To add to this, having the full expressive power of a programming language for syntax is the way to go. When you have to add explicit looping in your DSL, it’s time to not use a DSL.
HCL is my least favorite part of the hashicorp ecosystem.
Also it’s not like you have to take my word for it — the trend towards CDKs shows that pulumis approach was right. They were just early
This doesn't wash. The DOM is a declarative model, but that doesn't mean that a javascript program can't be a horror story of side effects and improperly grasped execution order.
Pulumi resources are immutable in the program after you declare them. I don’t think this analogy really works. It’s not like CDK - Pulumi does not compile down to an intermediate format.
When you write a Pulumi program you’re effectively creating a DAG in memory. The resources will be created in whatever order and with the maximum parallelization the dependencies allow.
I completely realize this, but simply the act of assembling that DAG in an imperative language adds a layer of cognitive load that is undesirable in something that's supposed to _declare_ configuration. Pulumi YAML looks tempting but it's simply not powerful enough to do a lot of things.
The other aspect of this is how it adds another requirement to your project - the setup and management of the language environment for the target language. Suddenly you've got another npm/bundler/etc. lockfile to keep up to date, your CI container images are double the size, your developers have another thing to fight homebrew to cooperate with...
Indeed, you cannot control the execution order (often much to my chagrin), only influence what the evaluator does via well-defined, declarative, options.
