> You sound like a marketer trying to sell a fridge on a phone call. I've got no stake in Dhall and I'm not a contributor. Check my submission history to see t

> You sound like a marketer trying to sell a fridge on a phone call. I've got no stake in Dhall and I'm not a contributor. Check my submission history to see the sorts of things I try to do at HN if you're curious what my agenda here is. > Why complicate my projects pipeline and force my team to learn yet another tool that may just be abandonned in 3 months? Dhall's substantially older than this and open source, so its not really an attrition risk in 2018. But I'd argue your pipeline is already complicated. My CircleCI2 flow got enourmously simpler when I was no longer struggling to represent complex concepts in YAML and could just produce an object graph in Dhall and then render it to the right YAML. I've also switched to using it to generate json for mesos API calls to make sure I get the fields right. > Or you could write a nice Python library, with clean API, and eventually a linter that makes sure the Python configuration file is a restricted subset of Python. I grant, this is possible. But why does having it "in Python" matter? How does that help people writing Golang or C# or Ocaml or Scala or Ruby? Dhall's decision to template out more standard files is a smart one, it means it can serve as a stand-in and let programs that do the heavy lifting of a product or process (e.g., a Python ML binding or airflow process) use their normal tooling and do what they love. If you're mad it is written in Haskell, I dunno what to tell you other than that it's like "jq". The host language doesn't matter because you invoke it for its outputs.