(It's the same with SQL, you describe what you want back rather than how its achieved. A declarative approach works fairly well there.)
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.
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.
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.
It's a hard to tell where marelle ends and the config begins, since it's all just prolog.
What would be the benefit of adding a declaritive language into the mix over YAML?
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.
YAML is not typed and you can basically do whatever. The worst of all worlds.
The capability to readily define, store in libraries, and use reusable abstractions that apply within a configuration or across multiple individual configurations.
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.