My circle also just use "code" as far as I'm aware, though I tend to think of it as a definition instead. Template would also fit but you can use templates within Terraform so that could be confusing.
As a long time terraform user, I've been playing with a spare time project in Pulumi. TF and Pulumi share providers, but that's the extent of it.
My quick observations:
* It's nice to write TypeScript as the configuration language
* The provider documentation is poor and lacks the examples that terraform has, I find my self reading terraform documentation to understand how to configure Pulumi.
* You're constantly fighting with "async" vs "Input" vs "apply" when using a value, basic cases are handled in Pulumi but as soon as you want to do something complex you're toast. Maybe I just am doing it wrong, but that goes back to the lack of docs.
* How it handles dev/production/staging is just a little off from my expectations, not that terraform at it's core does this well either (why terragrunt exists).
Overall it's not bad, but it's not a silver bullet either to the typical problems. And suffers from a "small" community problem where you can't google solutions to problems with the same success.
Your understanding is wrong. The CRUD logic of some commonly used providers is based upon that in Terraform providers, but the TF engine is not used by Pulumi.
No you’re not the only one. The problem with Terraform “Scripting” is in a lot of cases it takes a loooong time to find out your “runtime” errors. These are typically fat fingered strings. I think something like AWS CDK, where you find these errors at compile, time is a better approach.
I wasn't aware of this and I'm glad to see they're doing it. But my guess is this is a relatively recent offering in response to the AWS version and the issues I was mentioning.
terraform really needs to be run in CI/CD pipe. Even without the backend initialized you can run terraform validate which will find things like undeclared variables and messed up count and foreach references.
In my circle of engineers we tend to call it “code” but this isn’t ideal either - implies a general purpose language.