3 ms·

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 th

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.

4ad 4y ago
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.
numbsafari 4y ago
You’d think, as an industry, we’d have learned that parsing an introspecting config files shouldn’t have side effects.
- HelloNurse 4y ago
  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.
- klodolph 4y ago
  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.

4ad 4y ago

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.

numbsafari 4y ago

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

HelloNurse 4y ago
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.
klodolph 4y ago
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.