4 ms·

> 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.

by jen20 3y ago

> 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.

hardwaresofton 3y ago
Perfectly put. 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
ris 3y ago
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.
- Aeolun 3y ago
  Sure, but you still end up with a DOM afterwards, and you can compare that against a different DOM to determine differences.
- jkodroff 3y ago
  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.
  - jen20 3y ago
    Indeed, you cannot control the execution order (often much to my chagrin), only influence what the evaluator does via well-defined, declarative, options.
  - ris 3y ago
    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...

by jen20 3y ago

hardwaresofton 3y ago

Perfectly put. 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

ris 3y ago

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.

Aeolun 3y ago
Sure, but you still end up with a DOM afterwards, and you can compare that against a different DOM to determine differences.
jkodroff 3y ago
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.
- jen20 3y ago
  Indeed, you cannot control the execution order (often much to my chagrin), only influence what the evaluator does via well-defined, declarative, options.
- ris 3y ago
  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...