How CUE Wins (2021)
blog.cedriccharly.com
blog.cedriccharly.com
My hot take after all this is that it doesn't actually matter if your config language is Turing complete. Just use your regular programming language for config, I use typescript, it's great.
If for some reason you write an infinite loop in your config... you'll find out really quickly and fix it. Non-turing completeness doesn't actually solve any problems you care about, but using a crippled language does make simple things needlessly difficult.
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.
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.
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.
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.
(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 ;) )
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.
I wrote up some of how to do that here: https://earthly.dev/blog/yaml-validate-and-lint-cue-lang/
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.
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.
Also, the language is built to be modular, and many ready-made reusable parts are available, so you don't start from scratch when migrating.
Indeed it's set to win.
And from!
AWS SDK for Go has snippets that just work right in the docs. Writing some logic like “if attempting to use AWS types a, b, c, or send values outside this regex, error” is not that hard.
Having learned Puppet, Chef, Ansible, and having zero use for them day-to-day in the current reality of “beam API params”, a problem specific DSL seems like a dubious proposition.
I was an evangelist for Jsonnet but somehow it didn't get enough traction over time. I blame the lack of type support and integrations with the IDEs such as VSCode. I regularly check the VSCode & Intellij support for CUE as well but the support is still at the level of syntax highlighing, not more than that, which is sad.
Nowadays, I use VSCode with YML extensions (anchor, etc.) and use JSON Schema to validate the YML in the IDE with its language server. It's far from perfect but easy to iterate and portable.
CUE is a superset of JSON.
I don't think Turing complete or not matters a lot for a configuration language. What really matter are the toolchain support and the ability of express complex concept or relationships. Writing typescript with VsCode is a really pleasure and its type system is powerful enough to express complicate concepts. Besides typescript has mature packages systems which cue-lang is not ready yet.
With typescript you can easily do things like reading a json configuration via HTTP and override some varibles to generate the target json file you want, which would be hard to do the same thing with cue-lang.
As a conclusion, I don't think currently cue-lang would be a good solution for configuration generation. But I do believe it would get better in the future if the community keeps working on it.
[1]: https://news.ycombinator.com/item?id=34144566 [2]: https://kcl-lang.io/docs/user_docs/getting-started/intro/#vs...
Having gone decently down the Cue rabbit hole, I feel that Cue is remarkable in being able to do everything I need it to do without looking significantly different than JSON. The validations and boiler plate reduction are fantastic. And even without inheritance, I'm confident it can represent anything I need to without having to duplicate the same thing over and over.
If you want to use CUE as a library, you can only do it from Go at the moment. We are acutely aware of this limitation and we are investigating possible solutions.
1. CUE is a configuration language the author is promoting.
2. Author says CUE wins by becoming ubiquitous. :-(