You're setting up a false dichotomy. Expressing a dependency graph of cloud resources does not require a special DSL.
In fact if Terraform was a library it would not do everything nor do I want it to do everything. At the end of the day Terraform traverses a dependency graph and generates a sequence of commands to run. The traversal is basically a topological sort and the command generation is a bunch of API calls. None of those things require a specialized DSL.
And you still didn't answer my question. Based on your other comments Chef is your tool of choice for setting up servers because you can hack and glue things together how you want. That's great for you I get it. I assume you are a programmer by trade that wants to use the tools you feel comfortable with to get the job done. That's OK. I am an ops guy that is looking to make reproducible infrastructure without having to figure out awful Ruby/Chef bastardization. Terraform isn't a programming language. I understand you wish it was, but it simply isn't one. It's not the tool for someone that wants to program the infrastructure with Ruby.
I understand your point, but as a templating language the following should be expressible:
Given a list:
[ A, B, ... N ]
Create a list of objects:
[
{ foo: const, bar: A },
{ foo: const, bar: B },
{ foo: const, bar: C },
...,
{ foo: const, bar: N }
]
You say, why, this complicated programming task is not a job for terraform. Then why are some elements in place of the dsl functions, and some missing?
I have a feeling that the creators of may cloud tools don't use the cloud, or only to have pet infrastructures instead of pet servers. To set up something automated, complicated, scalable, reproducible, you have to result to do it yourself, while these tools are supposed to do it for you.
I feel like ops people are writing these tools for ops people, but instead of good old bash, now in Go. What is the problem with this?
* They reinvent well known patterns, but call them differently.
* They disregard the common knowledge of software development tradecraft.
* They don't get these things right for the first (or second time), just redo their previous workflows, and we are still where we were 10 years ago, just with different tools.
I personally prefer Ansible, but it has its weak points as well, and its development seems to have slowed since RedHat acquired it. The main advantages of Ansible are extensibility and reuseability. I can write custom modules, and have a descriptive DSL for stuff not thought of for the upstream devs. I can also simply reuse parts, which is a very weak point in terraform.
Still we use terraform, for it has its own merits, but IMHO if you want to do something, either do it, or don't do it, but don't do a half-assed "solution" which promises much, and fails to deliver. This is my feeling with terraform, where I could not even create a simple mapping of values, if those are not strings! (I know, "ops" people love strings. Only those pesky "devs" love structured data)
In fact if Terraform was a library it would not do everything nor do I want it to do everything. At the end of the day Terraform traverses a dependency graph and generates a sequence of commands to run. The traversal is basically a topological sort and the command generation is a bunch of API calls. None of those things require a specialized DSL.