Config as code? Yes, but keep it clean. Try some dhall.

There’s always a point where we are tempted to replace config files (json, toml, yaml), with just code. It’s handy, we get structure and abstraction, we can have little helper functions, proper comments (I’m looking at you, JSON). It’s especially useful when the config is verbose, or very common. The flip side of going the config as code way, is that we lose a lot: updating config is updating the application itself (not very 12 factor compliant, and not user-friendly as well when using compiled languages). Worse, some arbitrary side effects can sneak into your configuration step. Another issue is that it becomes really hard to read or analyze config files without launching the application itself (bye linters, bye dependency checkers, bye organization-wide metrics). If you want to do that properly, it means building a way to output generated configuration, building a sandbox to run the application, and a few other unsavory contraptions. All this issues stem from two things: – We have removed the boundary between application logic and configuration – We use a Turing-complete language to author configuration Thankfully, those two characteristics are accidental rather than essential to config as code. Dhall is a language designed to be used for config as code without compromising on what make config files great: clean separation between code and config, as well as predictable behaviour. It provides all the abstraction you need to author config files in a comfortable and flexible way (types, interfaces, functions), while being not Turing-complete (guaranteed termination) and allowing restricted side effects. In this session, we’ll see how we can author config files with Dhall, how we can read them from an application, and how we can use Dhall to generate JSON/YAML, in order to configure applications not able to use better technologies.