Configuration as Code

I've increasingly found myself drawn to writing declarations as programs, not as config in any plain textual format.Whether it's going all the way in the direction of supporting general purpose languages like Pulumi does, or with a niche but still Turing-complete language like Nix's expression language, or even Dhall, which other commentators have mentioned. That isn't to say there is no place for simple, human readable schema. I think these tools need a fallback to someth

As the article mentions, there's 'real' programming languages made for configuration, that solve at least some of the issues outlined, like Dhall, Cue, Jsonnet. After using both approaches a number of times (a general purpose language vs. one of the three), I'm imploring anyone trying to give this a shot to _not_ use a general purpose language.For instance: I'm mostly familiar with Jsonnet, which has guarantees that make it much easier to use than a Real Language: no

I think the future is that all configuration is code. Code in a proper functional/imperative language (preferably the one you wrote the app code in), rather than a special declarative language. The attraction of toml is minimalistic and simple definitions initially - but there is always too much logic for these languages. If not immediately, then eventually."Real" programming languages have good compilers, good error messages, debuggers, IDE's with syntax highlighte

I'm completely done with configs written in YAML. Easily the worst part of Github Actions, even worse than the reliability. When I see some cool tool require a YAML file for config, I immediately get hit with a wave of apprehension. These same feelings extend to other proprietary config languages like HCL for Terraform, ASL for AWS Step Functions, etc. It's fine that you want a declarative API, but let me generate my declaration programatically.Config declared in and generated by co

Looks like Dhall would be a perfect fit for you.> Dhall is a programmable configuration language that you can think of as: JSON + functions + types + importshttps://dhall-lang.org

Let's all write configuration in imperative turing-complete languages, what could go wrong...

Configuration as code, but in a quirky language - how about no? I'm sure someone uses this, someone created this, and so it might seem like it's useful, but we have enough clownishness out there with yaml, json combined with js, json with eval and so on.Create a framework in a normal language, but one which is very limited by design with regard to what is able to access - Skylark/Starlark is a good example[0], "limited Python" and use that. The rest works the same way

Have you seen the kind of "config files" YAML is being used nowadays? Gitlab CI, Ansible, Saltstack, various low-code tools... It's no better than a scripting language, because it turns out if what you need is to encode logic and control flow, you can't get away from it by shouting "DECLARATIVE" and pretending the problems don't exist. Pretty much all of these complex tools that use YAML don't use it for declarative purposes, but as a kind of hybrid AST&#x

"This declarative configuration format is great, but having to define 100 items by hand is tedious and error-prone. Let's make a DSL that supports conditions and loops!""This custom DSL is great, but there's zero tooling for it. Let's use a real language instead!""This Python-based config is great, but my config file takes ages to run, and even longer to understand. Let's make a simple declarative configuration format!"

each of those options have major downsides:- 'dumb data' (json, yaml, ...) is machine-, but not human-friendly. it's often tedious to write/read, and you can't abstract common parts out- DSLs are something you have to write, debug and maintain yourself. is the bug in your config or is it in your DSL's implementation? who knows!- full featured languages require a full blown interpreter and aren't tooling-friendly. as an example: with a Python package, i