[hjk05]

This isn’t an alternative to yaml. It’s a yaml generator. To me it’s not competing with yaml it’s competing with python or Haskell, and i’d argue that putting yet another language in your stack just for generating config files is added unneeded complexity. And sure while both python and Haskell are Turing complete, how often do we actually run into issues when generations flat config files? I mean I’ve never had that issue, and I’ve never caught myself thinking “if only there was a nice way to limit myself to a non Turing complete subset of python/Haskell”...

[guggle]

> i’d argue that putting yet another language in your stack just for generating config files is added unneeded complexity.

Well... I'd argue that when using Python I don't feel the need for a config file language in the first place... it's human friendly enough and I don't have to learn another syntax, use another parser, etc. I had to work on a Symfony project recently and I wish it wasn't sprinkled with all those yaml files.

> I’ve never caught myself thinking “if only there was a nice way to limit myself to a non Turing complete subset of python/Haskell”

Ditto... seems like bloat to me. There may be some use cases I don't know about but these config file languages tend to repel me.

[eridius]

That's kind of like saying C isn't an alternative to assembly, it's an assembly generator.

[HelloNurse]

On a practical level, C is an alternative to assembly because the appropriate black-box tools and combinations of tools allow the user to easily turn source code in either Language or a combination of both into an executable.

Generating assembly from C is an implementation detail, and many C compilers don't do that.

On the other hand, Dhall really is a YAML generator: the available tools allow only one-way conversion (in particular, there is no interpreter/library to ingest Dhall from the configured application itself).

[singpolyma3]

> in particular, there is no interpreter/library to ingest Dhall from the configured application itself

Not true. Perhaps this needs to be highlighted more prominently on the homepage. There are directly language bindings for Ruby, Haskell, and the JVM with more on the way.

[eridius]

Dhall is also a JSON generator. And you could write your own Dhall implementation that lets you consume it directly from an application if you want to, it's just nobody's considered that worth doing.

[hjk05]

Which is odd because tons of applications in the wild already have this amazing capability of directly consuming python and Haskell without first converting to yaml. But of cause you still have the ability to both produce and consume yaml if that’s needed for some reason.

[eridius]

What applications directly consume Haskell code? The only examples I can think of off the top of my head are apps written in Haskell that actually get recompiled any time you change the "configuration" Haskell code.

As for Python, that's because the Python interpreter can be embedded in an app.

That said, Dhall is exposed as a Haskell library, so if you're writing a Haskell app you could consume Dhall directly and skip the YAML. https://hackage.haskell.org/package/dhall-1.24.0/docs/Dhall-... shows examples of this.

[singpolyma3]

There is a tool to generate YAML from Dhall, but there are also language bindings for Ruby, JVM, and Haskell with more on the way. I don't think generating YAML will be a main use case for long.