Every Sufficiently Advanced Configuration Language Is Wrong

A thousand times, yes. I've wanted to write this same article. Thanks for saving me the time!

The industry is going to great lengths to avoid writing configuration in any ubiquitous imperative programming language. We're seeing the proliferation of hyper-specialized, clunky declarative languages with sub-par tooling and package ecosystems. In what world are templates acceptable code? I don't mean to pick on anything specific, but this[0] is the most recent example I've come across, and it's far from the most unreadable examples.

[0]: https://github.com/traefik/traefik-helm-chart/blob/master/tr...

I think for a lot of situations the key is to separate the language from the actual application.

So for example the application should always take a JSON blob, or some other simple format.

However the user will likely want to generate their configuration form something with the ability to control complexity like Jsonnet, CUE or just Python.

The problem with configuration expressed as a code is that it is not automatically auditable. With simple ini or json files, the auditing tool can just parse them, or, even worse, grep, and find out if a particular option has a certain legally-mandated value. This also applies to configuration files generated via templating - you just feed the end result to the auditing tool. With the code, the auditing tool would need to run the code, and this is a no-no from a security perspective.

I wish Ansible was just a python API. Past a certain point it would be much simpler.

"Its supposed to be state and not a procedure" is BS in my experience. When you need to do IFs, load vars, do things in order anyways...it stops being a state declaration.

It surprises me that the author didn’t mention Lua. More than just being a beautiful and simple language, it has been used for config-as-code in a variety of applications for years.

I miss systems use lex, bison, or their successors to define an appropriate configuration file format.

There ought to be some way to export the data structure definitions those things parse to, and then generate go/python/whatever bindings with IDE support for people that want to programmatically manipulate the config files.

Further, state-managing configuration languages lack sufficient hierarchy. Terraform providers are pretty nice but they aren't first class objects (resources) in the language and so dependencies between providers can fail to apply on creation (Kubernetes resources depending on a cluster created by managed resources is a common one) and there are some other weird edge-cases like dependency cycles that arise when removing or changing resources across provider version upgrades. Provider aliases help but aren't a complete solution. Similarly, providers for additional state management tools (such as Helm for k8s template management) don't have sufficient visibility into the state management of the encapsulated tool. What configuration languages need is arbitrarily deep nesting of state management with a well-defined interface to inspect and diff it from a higher level.

Most imperative programming languages aren't quite a natural fit for declarative management of resources because the general loop of how the tools work is functional evaluation of the declarative statements to instantiate the desired states of all managed resources, a reader to get the current states of managed resources, a dependency solver to help order the plans, a differ to produce a plan of what needs to be changed detect and show what will need to be changed, and finally the applicative layer to modify/create/delete managed resources by executing plans against APIs. This is a pretty functional model at every step (except perhaps plan execution, but in theory all executions should be modeled as edges on state machines of valid possible configurations and not as a spaghetti of if/then http/bash invocations) and so while it's certainly possible to implement configuration in imperative languages I think it will almost always fit functional languages a bit better.

I haven't implemented anything better than the current crop of tools, so take this with a pinch of salt I guess.

I wrote a configuration language for CTOS back in the day. It ran on a multi-processor box and was responsible for launching services in a coordinated fashion across the processors during boot.

Instead of a language, it was a schema for configuration statements. You edited the schema to add new launch commands, then added launch commands to the script.

It was pretty esoteric - used all three kinds of braces to express one-of, required, optional etc. The only person I knew who changed it other than me was Andrew Thurber (the one at Cisco). He was a new hire at the time, and I was startled to find he'd just read the schema-parser code and figured it out.

Anyway not sure how that approach fits into the OP's objections.

With languages like python, code itself can become configuration.

Declaring constants, lists, dicts, etc can be basic config, that is an importable python module.

Advanced config can be functions or some constructs around code that the program packages into a module during runtime.

I use protobuffers for configuration definitions and prototxt as actual configurations. For me it checks all the boxes: typed, complex objects support, readable, you don't have to worry about parsers.

I think the biggest offender of configuration language are the unintuitively multi-tiering of same settings but for different scope with varied ordering of precedence.

I am looking at you, Postfix `main.conf` and ISC Bind9 `named.conf`.

Damn near unauditable by machine code.

Any thoughts on HashiCorp Configuration Language (HCL)? I've found it pretty intuitive and sufficiently powerful when needs be.

The author does not take JsonSchema in account.