You're not seeing them strictly correctly, then:

All the tools described are declarative.

If "directly calling service API's makes the agent running the tool a SPOF" is a "bad" for Terraform, it also must be for Pulumi.

The idea that one "need[s] to be connected to, and have credentials for your environment to develop" to use Pulumi is equally true of Terraform, assuming by "credentials" you mean "credentials for the target provisioning platform".

The idea that "running your code requires bi-directional communication with the pulumi GRPC api" is also untrue.

It's important to be accurate when making these kinds of comparisons, lest you fuel memes instead of providing insight.

CDK nor Pulumi are declarative.

I've added the "agent SPOF", and "credentials" concern to Pulumi as well, it was an oversight.

Admittedly, my experience with Pulumi is pretty small, but I don't think I'm wrong about it needing a connection the pulumi parent process.

In-fact I opened an issue with Pulumi about problems with this in 2019, and they still haven't closed it.

https://github.com/pulumi/pulumi/issues/3590

Both CDK and Pulumi are declarative. The program declares resource desires to an engine, which evaluates a diff and effects change. You cannot instruct the engine what to do, only the desired outcome, which makes it declarative.

You are correct there is an engine - I mistakenly mistook that as criticism of the default state back end, which is not required.

Well yeah, I mentioned that at the end, CDK just produces a declarative cloudformation output. I think this is a good thing, but I wouldn't say that CDK is declarative, as you don't write declarative code.

You write code that specifies an outcome, and not steps to get there. That is declarative code, like it or not.

You can write literally anything you want in a CDK/Pulumi program. Depending on how you write it, the outcome could be different every time. The generated outcome, ie a cloudformation template, is absolutely declarative, but the CDK code is not.

I think this discussion is going on circles because you are both discussing different parts of the problem as if they are the same part.

A system could be said to have a declarative execution model if its input is a description of a desired result and that system then decides for itself what sequence of side-effects to perform to achieve that result. Terraform, CloudFormation, and Pulumi are all declarative by this definition.

However, there's also the question of how you tell the system how to build that data structure in the first place. CloudFormation and Terraform both do so with some form of DSL, with the effect that the source program perhaps more directly corresponds with the data structure it produces. Pulumi instead uses general-purpose languages to generate the data structure, and so the source code that produces it can, if desired, bare very little direct resemblance to the resulting data structure.

The tradeoff here then seems to be more about how far removed the input shape is from the resulting declarative data structure, rather than about "declarative or not". Some folks prefer the input to more directly match the underlying model, while others prefer to intentionally abstract away those details behind a higher level API.

I don't think either is right or wrong... I actually wish these two approaches were complementary inside the same product rather than two companies trying to kick each other in the shins, but that's capitalism for you, I guess.

You can do exactly that in Terraform too. Declarative and deterministic do not mean the same thing. Again, you cannot instruct the Pulumi engine.

The TypeScript CDK is the best use of TypeScript I've experienced. Just having all the documentation inline is hugely helpful, but the type checking also makes development faster by catching errors before you deploy (or even validate.)