The future of Terraform CDK • Hacker News Board

Re: The future of Terraform CDK

#31

Post by lijok » Wed, Dec 10, 2025, 8:16 PM UTC

dev_l1x_be wrote: post #19

It would be great to have an alternative to Terraform that uses a bit more advanced provider (at last for AWS). Does OpenTofu use that same provider?

It does. What are you looking for in a more advanced AWS provider?

Re: The future of Terraform CDK

#32

Post by lijok » Wed, Dec 10, 2025, 8:18 PM UTC

crimsonnoodle58 wrote: post #27

This is particularly frustrating as I've spent the last year writing many thousands of lines of CDKTF Python. HCL just does not have the modularity and expressiveness that Python, or other languages CDKTF supports. I guess I'll spend another year migrating to Pulumi now..

The lack of expressiveness of HCL is the point and what makes it so good

Re: The future of Terraform CDK

#33

Post by lillecarl » Wed, Dec 10, 2025, 8:18 PM UTC

mfornasa wrote: post #16

Rug pulls on infrastructure components seem even worse than other rug pulls as they can hit your entire infra codebase at once

This is why infrastructure people are conservative by nature, it's so damn much gruntwork to migrate without downtime

Re: The future of Terraform CDK

#34

Post by lijok » Wed, Dec 10, 2025, 8:19 PM UTC

Good move. They clearly didn't have the resources they needed. The design of the CDKs was atrocious.

Re: The future of Terraform CDK

#35

Post by stackskipton » Wed, Dec 10, 2025, 8:20 PM UTC

cholantesh wrote: post #24

scruff3y wrote: post #8

Earlier quoted context omitted.

Just use Terraform?

Yeah I'm struggling to see the value here.

The value for TFCDK was Developers don't have to learn another language, they can just continue to use existing language they already know.

Downsides are doing infrastructure in a programming language was always problematic unless developer was skilled at Ops which most who used TFCDK were not.

Re: The future of Terraform CDK

#36

Post by lillecarl » Wed, Dec 10, 2025, 8:20 PM UTC

sshine wrote: post #9

GardenLetter27 wrote: post #6

Damn, what are the best alternatives here? For pure AWS I guess CDK directly is okay, but locks you in.

Terranix? ;-)

Yes, the NixOS module system is so much more composable than the TF one

Re: The future of Terraform CDK

#37

Post by tonnydourado » Wed, Dec 10, 2025, 8:22 PM UTC

NeckBeardPrince wrote: post #22

Hashicorp, an IBM company

Hashicorp,an IBM company

Re: The future of Terraform CDK

#38

Post by lijok » Wed, Dec 10, 2025, 8:24 PM UTC

cube2222 wrote: post #30

Hamuko wrote: post #23

Earlier quoted context omitted.

Does it do ephemeral values yet?

Yep, as of yesterday’s 1.11 release it’s supported! That also includes a new “enabled” meta argument, so you don’t have to hack around conditional resources with count = 0. [0]: https://opentofu.org/blog/opentofu-1-11-0/ Disclaimer: affiliated with the project

How do you migrate from count/for_each to `enabled` ?

Re: The future of Terraform CDK

#39

Post by packetlost » Wed, Dec 10, 2025, 8:25 PM UTC

vbernat wrote: post #2

It's odd to always say "Hashicorp, an IBM company". Looks like they want to assign blame. I did try Pulumi a while back, but the compatibility with Terraform modules was not great, so I've switched to CDKTF, which can handle unmodified modules. Dunno if I'll switch back to Pulumi or just use OpenTofu directly.

I have absolutely nothing good to say about Pulumi. Stay far, far away.

Re: The future of Terraform CDK

#40

Post by jpitz » Wed, Dec 10, 2025, 8:28 PM UTC

dev_l1x_be wrote: post #19

It would be great to have an alternative to Terraform that uses a bit more advanced provider (at last for AWS). Does OpenTofu use that same provider?

The providers for tofu are by design the same as for terraform.

Also, for large providers like AWS, GCP, Azure, etc - these are often largely authored by the hyperscaler themselves, for better or worse.