Each clouds SDK in the language the team is most familiar with is by far the best option.
State can be stored in git. Any version of my infrastructure is a git checkout away.
I use Go, and the documentation for the AWS SDK includes copy-paste examples
Try and checkout Terraform from 6 months ago and run it? Frequently I cannot even get someone’s tutorial example written a week prior to work without edits.
I checked out a year old commit in my infra repo; rebuilt an entire ECS stack deprecated 18 months ago.
Just be programmers. The cloud ops scene is just reselling the same delusions as Unix grey beards and Windows server admins. It’s about making hardware do the right thing, not hand wavy semantics.
Most of the people I work with just regurgitate memes. Very few actually test them for truth.
Creating resources with the SDK is easy—keeping them in the desired state is very hard.
Instead, we use a real language to generate a description of what we want (in YAML or HCL) and a reconciliation engine takes over from there.
1. It's slow to return results
2. sometimes the only way you can generate a list of available properties is to type the first character, which is really annoying if you don't even know what the first character might be
3. it offers suggestions for properties that aren't even valid for that resource
4. there is no description against any of the properties so you're still left guessing (or having the docs open in another window) anyway
Terraform offers far more constructs than CloudFormation and there is still a lot to be said for using the same language from describing your AWS infra as GCP, Github, any on prem infra, etc (even if the resources differ between providers requiring bespoke code for each). It's a bit like those who advocate node.js because it means the same developers can right frontend and backend code and in the same language.
If you like the tooling around CloudFormation in AWS then you're better off with serverless (`sls`) or even Amazon's own CDK (https://aws.amazon.com/cdk/) over YAML-based CloudFormation stacks in my opinion.
That's not to say I don't think Terraform doesn't have its warts: properties are non-guessable, IDE integration is pretty mediocre, and it's overly verbose in calling modules (so bad that sometimes the calling code has just as many lines as the module itself!) but I do still think it is the least worst tool available at the moment. And one can always use a 3rd party tools like Terragrunt if you want to fix some of the shortcomings of Terraform while still taking advantage of it's benefits (though personally I'm on the fence about whether the industry really needs yet another transpiler that compiles to code that needs to be transpiled....it's starting to feel like it's just abstractions all the way down....)