What is the selling point for this vs say Dhall, which looks superficially similar (Haskell-ey config lang)? The examples for Nickel currently look a lot more

What is the selling point for this vs say Dhall, which looks superficially similar (Haskell-ey config lang)? The examples for Nickel currently look a lot more like programming than config. Why not just use a general purpose programming language that you already know and has many libraries and mature tooling? Dhall advertises a lack of Turing-completeness as a feature. One of the Nickel examples shows an implementation of fibonacci function... (I have no idea if this implies Nickel is TC, nor why I would need such power in my config) > Dhall features a powerful type system that is able to type a wide range of idioms. But it is complex, requiring some experience to become fluent in. > Gradual types also lets us keep the type system simple: even in statically typed code if you want to write a component that the type checker doesn’t know how to verify, you don’t have to type-check that part. > Complementary to the static type system, Nickel offers contracts. Contracts offer precise and accurate dynamic type error reporting, even in the presence of function types. It's not clear to me that gradual typing as a mix of statically typed code + untyped code with "contracts" is necessarily simpler than just one or the other. It's not clear to me that a specialised config language combining code + schemas is necessarily better than an existing general purpose language + some language-agnostic schema DSL. I don't know, maybe this is all great, I feel the benefits need to be more clearly explained and demonstrated though.