Comment by nothrabannosir
2 days ago
Couldn't disagree more.
I have written both TF and then CDKTF extensively (!), and I am absolutely never going back to raw TF. TF vs CDKTF isn't declarative vs imperative, it's "anemic untyped slow feedback mess" vs "strong typesystem, expressive builtins and LSP". You can build things in CDKTF that are humanly intractable in raw TF and it requires far less discipline, not more, to keep it from becoming an unmaintainable mess. Having a typechecker for your providers is a "cannot unsee" experience. As is being able to use for loops and defining functions.
That being said, would I have preferred a CDKTF in Haskell, or a typed Nix dialect? Hell yes. CDKTF was awful, it was just the least bad thing around. Just like TF itself, in a way.
But I have little problems with HCL as a compilation target. Rich ecosystem and the abstractions seem sensible. Maybe that's Stockholm syndrome? Ironically, CDKTF has made me stop hating TF :)
Now that Hashicorp put the kibosh on CDKTF though, the question is: where next...
This does not match my experience. Terraform validate will check for types and you have great IDE support with refactor, find usages, resource documentation and everything else you might expect. You can of course build a monster of untyped dictionaries but that’s true for almost any language. Do you have examples of something else that the validation step does not find?
I never had this integrated with an editor but maybe I didn’t try hard enough. With CDKTF, a stock typescript IDE automatically has tab complete for every provider you want. That + being able to use functions, variables, loops, arrays, and structs for composition made it a completely different experience.
If those things all end up coming to terraform I’m all ears. For now it seemed more like a compilation target.