Yes, that's the problem. I'd like to be able to look at a config file, on disk, loaded at startup, which defines the initial state of the server without having to think through how it was evaluated.

Generating the config during deployment, eh... often necessary. Best done with transforms and templates because they're simple.

Executable config, run during startup or, worse, on each request? NO.

[edit] I think that's the main disconnect here: 'past compile time'. The whole point of testing, strong type systems, etc is to lock down the set of states the system can be in. If your configuration is so 'dynamic' you are essentially abandoning all those benefits and saying 'yeah, do what you like to our live servers'.

In short, configuration which is that powerful is indistinguishable from running untested code in production.

Dhall give you exactly that, since you can store the normalised version of any configuration. Or inspect it at will by running it.

Yes, I'm not criticising Dhall so much as the behaviours it permits. IMO it should be difficult to 'program' the generation of a config file, because the application should be designed such that that degree of flexibility is not required at the level of configuration.

We've done things with generated config before. Looked necessary. We took a few steps back and realised that it was never necessary, only permitted, so it got fudged in deployment instead of being fixed in application design.

If you operated services that should run at scale, or 24/7, or both, you must have noticed that the ability to fix an urgent issue (which may be totally not a fault of the deployed code) by changing just configs is valuable.

Of the failure modes I've had to deal with, even when we did use a lot of interpreted scripts which could be live-patched, very few of the important issues were fixable that way. Because the stuff which broke was rare and deep.

One could argue that everything would be config-related if all the code were interpreted and considered to be configuration. So absolutely everything could be fixed in Production.

I'd argue that absolutely everything could be broken in Production too, in that case. The point is that you test the invariant stuff, and have a small surface area of variables which define the permutations of Live behaviours.

Configuration is not code. Code gets tested and doesn't vary between Canary, Nightly, Stable Test, Customer Test and Customer Live for a given build.

Because some of us build stuff for customers who won't justify the 'risk' of updating every day, and have upgrade cycles measured in months.