Earlier quoted context omitted.
Based on everyone's feedback about YAML (we didn't expect this much), we'll probably reconsider this!
Glad to hear it! To synthesis my comment down (because it's easier once I've written it once, poorly): The complexity you see in Bazel/Buck/Pants build files may seem like a result of their decision to use a programming language. That's a red herring. That complexity is fundamental to the problems people need to solve to build software. If you remove the ability to solve it in your build system the complexity will mo…
Glad someone else brought up this topic and phrased it way better than I ever could have!
This other comment further down puts it very well, too: https://news.ycombinator.com/item?id=34892724
> If you remove the ability to solve it in your build system the complexity will move to other systems.
Adding to this: I think one of the main limitations of purely declarative (e.g. YAML-based) configurations is that a declarative DSL (as opposed to an imperative DSL) means you (only) get to use config options the inventors of the config language have thought of and implemented (i.e. "defined"). You cannot put into words things that require vocabulary that doesn't exist in your language.
Meanwhile, an imperative language gives you the ability to define on your own what you would like the machine to do.
As an example, consider Gitlab CI configs (YAML-based) or Ansible playbooks. In both cases, once you hit the boundaries of the DSL spec (which, in my experience, typically happens on day one) you can't do anything other than 1) give up or 2) leave the realms of the DSL and as you say,
> move [the complexity] to other systems