3 ms·

I have a vested interest in this argument, because it comes up all the time. From your argument, it's apparent you've never written a program in anything except

I have a vested interest in this argument, because it comes up all the time. From your argument, it's apparent you've never written a program in anything except a configuration language. But by your own admission: > You are not declaring what it looks like, you are writing instructions for how to produce declarative If this was true, a Pulumi program would look like this: const bucket = new aws.s3.Bucket() if (bucket) { // do something } else { // do something else } If you'd written anything in Pulumi you'd know that isn't how it works. The only imperative part of Pulumi is your ability to manipulate the DAG, for example: const config = pulumi.Config() const createBucket = config.reqiureBool("createBucket") if (createBucket) { new aws.s3.Bucket() } Now, is there an imperative statement in there? Yes, but the only imperative part is your decision to include or exclude the bucket itself from the declarative end state. You do _exactly_ the same thing in Terraform but with a less intuitive syntax: resource "aws_s3_bucket" "example" { count = 0 } By that definition, if Pulumi is imperative, so is Terraform. It's not though, and you're wrong.

verdverm 4y ago
> From your argument, it's apparent you've never written a program in anything except a configuration language. Way to assume, you know how that usually turns out? Could I condition the creation of a bucket based on the even/odd value of a different resource's hash? What about the time of day or day of week? What other arbitrary things might I be able to do in a language that Pulumi supports? How can I be sure that if I run the code on a different day, that the outputs are stable? Let's consider another idea... can Pulumi prevent me from making arbitrary calls to an API or database to fill in the "declarative code" that creates a resource? Would something like that be imperative or declarative? Does/can the order I write Pulumi code in matter? Does it for TF? Can you interact with the outside world with custom code in TF between the creation of resources? In the end, are you writing the desired state directly or instructions for how to construct that desired state? I invite you to consider these questions with the others you have discussed Pulumi semantics, as I assume I am not going to have success getting you to do so here... You can likely do some of the above with TF, as it has strayed further from declarative. What you really want for configuration is a language which is not Turing complete and does not support dynamic values within the code, only via flags / args at invocation time. In other words, same outputs from the same inputs. I think TF & Pulumi both fail on the latter (https://www.richard-towers.com/2021/01/03/terraforming-advent-of-code.html https://www.richard-towers.com/2021/01/03/terraforming-adven...) (https://cuelang.org https://cuelang.org)
- jen20 4y ago
  What you appear to be saying is that Kubernetes is declarative if using YAML but not if using client-go, which is patently ridiculous. The answer to your question is that you are constructing the desired state, not instructions for how to get from the current (unknowable) state to it. Using an API to construct declarative configuration is actually an incredibly useful pattern. Terraform can do it with HCL, too.
  - verdverm 4y ago
    When you use client-go, you step away from the declarative interface to Kubernetes, much like when using Pulumi to step back from the TF interfaces. Kubernetes has itself strayed from being purely declarative and provides several mechanisms for transforming and modifying incoming resources during the admission and scheduling process, so you cannot actually be sure what you submit is what will be running anymore. Again, declarative vs imperative is a DX issue. All the systems underneath are using both. So if we follow your logic, that the underlying system is what matters, every experience would be both imperative and declarative. Kubernetes and Terraform both use imperative processes to implement the declarative input. Using the properties of the underlying system to describe the exposed DX makes no sense. You don't get to add imperative on declarative or declarative on imperative and claim it has the property of the system you just layered on top of. The outermost layer, the one exposed to the end user, is the type of system (declarative or imperative) that the user is using. Pulumi and client-go are both imperative interfaces on top of other systems. Go fish...

verdverm 4y ago

> From your argument, it's apparent you've never written a program in anything except a configuration language. Way to assume, you know how that usually turns out? Could I condition the creation of a bucket based on the even/odd value of a different resource's hash? What about the time of day or day of week? What other arbitrary things might I be able to do in a language that Pulumi supports? How can I be sure that if I run the code on a different day, that the outputs are stable? Let's consider another idea... can Pulumi prevent me from making arbitrary calls to an API or database to fill in the "declarative code" that creates a resource? Would something like that be imperative or declarative? Does/can the order I write Pulumi code in matter? Does it for TF? Can you interact with the outside world with custom code in TF between the creation of resources? In the end, are you writing the desired state directly or instructions for how to construct that desired state? I invite you to consider these questions with the others you have discussed Pulumi semantics, as I assume I am not going to have success getting you to do so here... You can likely do some of the above with TF, as it has strayed further from declarative. What you really want for configuration is a language which is not Turing complete and does not support dynamic values within the code, only via flags / args at invocation time. In other words, same outputs from the same inputs. I think TF & Pulumi both fail on the latter (https://www.richard-towers.com/2021/01/03/terraforming-advent-of-code.html https://www.richard-towers.com/2021/01/03/terraforming-adven...) (https://cuelang.org https://cuelang.org)

jen20 4y ago
What you appear to be saying is that Kubernetes is declarative if using YAML but not if using client-go, which is patently ridiculous. The answer to your question is that you are constructing the desired state, not instructions for how to get from the current (unknowable) state to it. Using an API to construct declarative configuration is actually an incredibly useful pattern. Terraform can do it with HCL, too.
- verdverm 4y ago
  When you use client-go, you step away from the declarative interface to Kubernetes, much like when using Pulumi to step back from the TF interfaces. Kubernetes has itself strayed from being purely declarative and provides several mechanisms for transforming and modifying incoming resources during the admission and scheduling process, so you cannot actually be sure what you submit is what will be running anymore. Again, declarative vs imperative is a DX issue. All the systems underneath are using both. So if we follow your logic, that the underlying system is what matters, every experience would be both imperative and declarative. Kubernetes and Terraform both use imperative processes to implement the declarative input. Using the properties of the underlying system to describe the exposed DX makes no sense. You don't get to add imperative on declarative or declarative on imperative and claim it has the property of the system you just layered on top of. The outermost layer, the one exposed to the end user, is the type of system (declarative or imperative) that the user is using. Pulumi and client-go are both imperative interfaces on top of other systems. Go fish...