I'm working on developing a new Infrastructure as Code (IaC) language that shares some similarities with Terraform, particularly in using 'resources', but differs in many other ways. I'm really interested in hearing about any pain points you have with Terraform or specific features you wish were included. What annoyances should I avoid repeating in my project?
5 Answers
It really depends on your goals. Terraform's control can be limited due to cloud provider APIs, and if state files aren't managed well, it can get tricky. I've been focusing on IaC for the Proxmox platform, and being non-platform agnostic gives me much better control. If you're aiming for a provider-agnostic tool, you might find it challenging as Terraform’s strength lies in its provider flexibility.
Totally! The way Terraform is set up feels limited, that's why something new could really allow users more versatility.
I'm not really a fan of DSLs like Terraform; they seem outdated. More and more folks are leaning towards full programming languages like Pulumi and the Cloud Development Kit (CDK). Just my two cents.
Has the trend really shifted that much?
I understand where you're coming from, but have you compared the code for resources declared in a DSL versus a full language? Sometimes using Python for a simple bucket feels chaotic.
You might want to start by clarifying what specific problems your language aims to solve, and why the existing options aren't sufficient. This way, it will be easier for users to see the value.
That's a solid point. Plus, have you considered contributing to existing projects like OpenTofu instead of creating yet another tool?
Also, I've found Terraform quite confusing because it mixes resource properties with expressions like 'for_each'. It's verbose and its state management can be a nightmare, downloading everything from the backend all the time. Definitely something to think about!
Why create another IaC tool? Adoption isn't just based on one or two features. You'll need to consider things like usability, cost, and various required functionalities to really stand out. If this is for personal learning, that's cool, but you might find useful insights in the open issues on GitHub for Terraform and OpenTofu.
Great tip! I'll check the open issues. As for design, I believe I’ve crafted a pretty solid developer experience; would you be willing to provide feedback if I share it?
Interesting analogy... but why not have many options like car brands? There's always room for innovation!
Take a look at this resource: [Survey of Config Languages](https://github.com/oils-for-unix/oils/wiki/Survey-of-Config-Languages). Personally, I find the concept of Turing completeness in config files pretty limiting.
Funny enough, that page has a brief mention of HCL which is exactly what you'd want to know more about.
I haven’t seen that before, but I’ll definitely check it out to understand more about Turing completeness.
What exactly are you working on with Proxmox? I agree that the provider approach works well but it could really use a layer that allows for high-level resources to be used across different providers.