To play devils advocate, isn't the idea with Ansible at least that it's idempotent. The YAML should describe the final state and should be concerned with branching or lower level features like that.
(It's the same with SQL, you describe what you want back rather than how its achieved. A declarative approach works fairly well there.)
However, that final YAML-defined state is not guaranteed to define the entire functionality of the system. The typical counterexample is this: removing a 'create file' clause does not cause that file to be removed on subsequent runs, as the tool has no concept of ownership nor diffing against previous states. The emitted YAML does not represent the indended full state of the machine, just what actions to take to bring it from some unspecified historical state to an underspecified target state. There is no guarantee of consistency.
Thus, it is very easy to get in a situation where an Ansible playbook applied against two machines with slightly different production history will result in very different behaviour.
If you want real declarative configuration management, try Nix/NixOS.
> removing a 'create file' clause does not cause that file to be removed on subsequent runs, as the tool has no concept of ownership
Terraform on the other hand does have a concept of ownership, diff-ing, and applying changes. It takes some work as you now need to track state, but I've been very happy with Terraform.
> isn't the idea with Ansible at least that it's idempotent.
Sure, that's true with many of these, so what?
The problem isn't that the languages are declarative—functional code is declarative.
The problem is that they are extremely limited in their expressive capabilities, so that it is much more complex and error prone to describe the final state in them than it would be—even in a declarative style specifying the final configuration—in a more complete language than YAML (or, in many cases, a language essentially limited to JSON’s expressive capability even if it also supports a YAML serialization.)
> It's the same with SQL, you describe what you want back rather than how its achieved.
YAML would be an inadequate alternative for SQL’s role, too.
While (most) actions in Ansible modules are idempotent the entire playbook is not. So how your system is going to look at the end of a run is highly dependent on the order of everything in your YAML files and the current state of the system. You can ensure a file exists in and part and remove the directory containing it in another, and you are non the wiser unless you run the playbook multiple times and pay attention to the changes.
Emacs is configured using Lisp. Because of that it is amazingly configurable.
XMonad uses Haskell, which gives types to avoid lots of error cases.
The thing is providing an actually programming language doesn't remove anything specially if the same config can be written as cleanly.
And you would avoid "YAML templates for creating YAML", when you actually need to process some data (even if it's just for pre/suffix creation in names). Secrets retrieval is another thing that you also need to do and template.
Also, YAML is a terrible to parse language, with can give out weird error cases. Other languages compilers/interpreters are more mature.
And ofc, if you provide SDKs for your IaC tool, you should be able to use the language that your developers are more familiar with. Taking advantage of the good practices their are used to. Don't limit with "declarative languages". Use a programing language that make more sense, and leave data languages for data.
> What would be the benefit of adding a declaritive language into the mix over YAML?
The capability to readily define, store in libraries, and use reusable abstractions that apply within a configuration or across multiple individual configurations.
What's needed is an internal data-structure that defines the state needed -- YAML declares the structure directly, but an alternative is to use either a DSL or even a general-purpose language to build that data-structure.
Of course, you could write code to generate your YAML, but the tooling is _not_ going to help you with that today.
Maven and Gradle are examples of each of these methods -- both build up an internal model of the build, but while Maven uses XML, Gradle uses a Groozy DSL.
I'd argue somewhat that the approach works well for SQL. On a superficial level it allows you to hide the implementation details of your query execution. In practice not so much. Hence keywords like "explain" were invented and statements like "CREATE INDEX". And table partitioning. And hints. And myriad of other practices where the SQL abstraction "leaks" details from the layer below.
(It's the same with SQL, you describe what you want back rather than how its achieved. A declarative approach works fairly well there.)