More than the language syntax, getting any response from the hashicorp team on their official providers is like rolling the dice. If your bug or feature pr is a bit on the fringes and not in their sights, it can sit for months/years without traction or even a non-automated response. With just the aws provider, there are over 3000 issues and nearly 400 open PRs. That team is understaffed or mismanaged. It has gotten marginally better over the last year or so, but generally speaking, Hashicorp doesn’t seem to care while they’re pouring all efforts into their own cloud. 1. https://github.com/hashicorp/terraform-provider-aws/issues/1... 2. https://github.com/hashicorp/terraform-provider-aws/issues/6... 3. https://github.com/hashicorp/terraform-provider-aws/issues?q...
I’ve built custom Terraform providers to map to custom APIs, and the experience was just fantastic. I’ve also used scripts with AWS resources that were a chore to use because the underlying API was a trash fire.
Specifically with respect to Terraform the language, the uniform adoption of functional programming concepts would be nice— right now providers expose varying ways of dealing with sets of resources in more or less confusing and incompatible ways (count, and the various times that you cannot use count).
So the problems with TF are twofold: the language is not quite consistent, and the ecosystem depends entirely on the quality of contributed providers and/or the module shims built on top of poor providers.
It can be easy to get frustrated during IaC development, but an absolute relief when you can rock deployments confidently.
A lot of us have cut our teeth on previous major version of terraform DSL, when it was even less capable than it is now (no maps, no for each, etc.) and it wasn't that uncommon to be told to generate terraform JSON directly to work around DSL shortcomings, generating essentially all of the provider objects yourself.