Comparisons between CUE, Jsonnet, Dhall, OPA, etc.

[cueckoo]

Originally opened by @klauern in cuelang/cue#669

Are there any references to help explain the differences between CUE and some tools that I believe (feel free to correct me if I'm off-base) are similar?

• JSONNET
• Dhall
• OPA (as well as Conftest)

I'm completely unfamiliar with CUE, but I have seen the above three used for generating YAML for Kubernetes, or evaluate compliance of those against internal policies. Is CUE a good fit for that kind of work? Is it suited for other kinds of work? I see a number of items in the Use Cases that make me think that CUE is in the same space, but I am not sure if it's worth looking into it at this time considering I have some experience with the above three. Is there a page or links to sites that help explain where CUE shines or what would make it stand out compared to those?

[cueckoo]

Original reply by @mpvl in cuelang/cue#669 (comment)

CUE was developed as an answer to the pitfalls of GCL (very much like Jsonnet). See the discussion in https://cuelang.org/docs/usecases/configuration/. It is based on an 30-year old approach from NLP, where it was used to model large 100k lines up configurations (grammars and lexicons), maintained by distributed groups of teams.

Dhall addresses some of the issues of GCL and Jsonnet (like lack of typing), but lacks the detailed typing of CUE. But it still misses the most important property of CUE: its model of composability. Some of the benefits are explained in the above link. Conceptually, CUE is an aspect-oriented and constraint-based language. It allows you to specify fine-grained constraints on what are valid values. These constraints then double as templates, allowing to remove boilerplate often with the same efficacy as inheritance, even if it works very differently.

The lack of override inheritance in CUE also makes it much easier to see where values are coming from. A value is always final in CUE, it can only be made more specific. This is in stark contrast with inheritance or other forms of composition, where values can often be overridden many times, making it very hard to see where values come from. CUE's approach leads to big improvements in maintainability. It may be harder to write initially, partly because its conceptually so different from the other languages, but it is considerably easier to maintain.

I would argue that for configuration languages maintainability and readability are more important even than for programming languages, because they are ofter viewed by a larger group, often need to be changed in emergency conditions, and also as they are supposed to convey a certain contract. Most configuration languages, like GCL (my own doing), are more like scripting languages, making it easier to crank out definitions of large swats of data compactly, but being harder to comprehend and modify later.

CUE also can be used for policy specification, like Rego (OPA).CUE unifies values, types, and constraints in a single continuum. As it is a constraint-based language first and foremost, it is well suited for defining policy. It is less developed in that area than Rego, but it I expect it will ultimately be better suited for policy. Note that Rego is based on Datalog, which is more of a query language at hart, giving it quite a different feel for defining policy than CUE. Both are logic programming languages, though, and share many of the same properties.

OPA itself, though, is more of a product. CUE is more like Rego, the language used in OPA. It could make sense, for instance, to have a CUE frontend to OPA.

I hope this helps a bit.