I don't particularly care whether a language is Turing-complete or not. In the case of CUE, I like it because (a) unification is commutative, so I can define things in the most appropriate place (e.g. a company-wide repo, or project-specific, or for dev environments, etc.) and it makes no difference to the end result and (b) it has no side-effects, which avoids the temptation to e.g. open external files, or look in env vars, or download something, etc.

You’d think, as an industry, we’d have learned that parsing an introspecting config files shouldn’t have side effects.

It's the eternal opposition between taking shortcuts and doing things the easy, cool and dangerous way vs. planning and optimizing and doing things the boring, slow and cautious way.

In the specific case of configuration files, the danger is easy to underestimate because configurations are often considered a minor, easy,low value part of an application.

I think you may be overestimating how universal the lessons are.

For more complicated configs, a common approach I see is that the “config file” is a program that generates the actual configuration data. If you just need to parse and introspect the config data, you fetch the build output and parse that, which does not have side effects.

One big advantage of CUE being a total language is that you can always evaluate it in very different contexts. Yes, it doesn't matter whether your config is TC or not if all you do with it is configure one single program. If you have an infinite loop in your configuration instance (or if you think you have, assuming you haven't solved the halting problem) you will just fix your configuration for that specific program.

But large systems are not like this. There is no single configuration instance, configuration is pulled from all kinds of places, and each part of the system sees a different subset of configuration. And very importantly, this changes over time. The impact of a single change in some place becomes very hard to predict. Making the language total is one way we can limit the impact of configuration changes. Others that you mentioned are commutativity and the lack of side effects.

Also, being total means you can freely evaluate CUE outside other contexts than simply program configuration. For example, you can do configuration testing independently of deployment, or you can do large scale automatic refactoring, you can inspect the system in arbitrary ways, etc.

An infinite loop is not the most frequent type of non-termination. Crashing is.

When your "config" fails to load halfway through its interpretation because of a KeyError, ValueError, NullPointerException, "null has no method <whatever>", you see some of the downsides of Turing-completeness.

Crashing is termination; the reason it's tricky is that we often treat programs as having return type "Foo" when they actually have return type more like "Foo | Stacktrace".

(Sometimes it's easier to do theoretical work by replacing crashes with infinite loops; but that's only because it's impossible to do the converse ;) )

given your argument, it seems your gripe is with object orientation rather than with turing-completeness.

Rather, with dynamic languages used for config files. I could use Lisp or Lua for the example, but they are not as recognizable in this role.

Hum... I do agree that totality is overrated. I never saw anybody complaining that they had to write configuration in a Turing complete language, and I can't imagine a situation where people will scratch their heads looking at typical configuration code and wondering where the infinite loop comes from.

But purity is extremely underrated. Configuration changing due to changes on the environment is a huge problem. Network dependency is kinda ok if it exists on a single place, and determinism is assured when everything works, but if it is going to exist in a single place, that place can not be every configuration file. And all the extra I/O features of your random language must not be used, what isn't a big problem, but having things around that must not be used is always a small drag.

The sweet spot I found for CUE was when you have existing YAML, you add CUE types externally and then validate your yaml without needing to change the program. It's like a baby step towards moving beyond YAML.

I wrote up some of how to do that here: https://earthly.dev/blog/yaml-validate-and-lint-cue-lang/

At the end of the day we’re structuring syntax in a file within the constraints of some compiler or interpreter, which itself is implemented as structured text.

Engineering is about keeping it simple. So I agree; we can avoid dozens of flavors of structured text (using up worker time to learn, compute cycles to use) and stick to general programming languages rather than prove how clever we can be by creating yet another tokenizer, parser, writer with some hand wavy, tangential connection to mathematical concepts.

The problem with using a general programming language for configuration is you end up needing to use that config in different places, in different contexts, and from different languages. So, you have to marshall out and marshall in that structure to some intermediate format.

You want it to be easy for humans to edit and grok, so you find a way to represent the core parts you care about as text and cordone off the general programming language to another area.

You're successful and the number of use cases you cover grows, so the size of that config grows.

And before you know it, you've invented YAML.

Whereas, if you use Cue instead of YAML it looks pretty similar - in fact some large subset of it will be parsed correctly by a YAML parser. But the difference is with Cue you can: 1. Validate the structures in your config 2. Deduplicate by referencing other values in your config (something you can't do in JSON/YAML). 3. Use language built-ins to reduce boiler plate and repetitive text.