https://bitfieldconsulting.com/golang/cuelang-exciting
…which does a nice job of starting from the problem, and building up from "how could we improve JSON for use as a config language" to arriving at CUE.
(Those types of explanations happen to resonate with me, including understanding the "why" first at least for me helps the mechanics and details later make more sense and feel more intuitive…)
* How does CUE compare with a standard structural typing system, i.e. Typescript. Specifically, what is the deep difference between
john: #Person & {
age: 29
hobbies: [
"physics",
"reading",
]
}
type Person = {
age: number
hobbies: string[]
}
const john: Person = {
age: 29
hobbies: [
"physics",
"reading",
]
}
* Where is the line between a data language and a full fledged programming language? For example, the list package, while (intentionally?) missing map / fold, indicates a strong demand for rich list processing capabilities. https://pkg.go.dev/cuelang.org/go@v0.4.0/pkg/list
For example, one file might have the constraint "john is an int" and the other "john is between 1 and 7". If the constraints clash (e.g., john is an int and john is a string), then it's an error.
That said, I think my disconnect is "when is this useful?" or "what can I do with this property?".
CUE's constraints are in the "middle" of the spectrum (lattice, partially ordered graph) from abstract types to concrete data.
It is specifically not inheritance where overrides are allowed.
A canonical use-case for data languages is a cloud deployment consisting of many almost identical items, e.g. k8 pods, described as a series of data templates with the the property that the cost of overriding any (shared) configuration parameter over the entire deployment is O(1).
In a standard function-based language this can be done by rewriting function arguments at runtime, i.e. some form of monkey patching. I haven't seen a good theoretical explanation on how data languages (GCL, jsonnet, CUE, etc.) avoid the monkey patching trap as opposed to embracing it with good terse monkey patching syntax & semantics.
Perhaps there is a there there, but until the basic evaluation semantics is clarified, I have little hope of grokking higher level concerns like typing.
> In a standard function-based language this can be done by rewriting function arguments at runtime, i.e. some form of monkey patching. I haven't seen a good theoretical explanation on how data languages (GCL, jsonnet, CUE, etc.) avoid the monkey patching trap as opposed to embracing it with good terse monkey patching syntax & semantics.
I'm not entirely sure. I know you can arbitrarily layer on more constraints (e.g., you can impose your own naming conventions onto a Kubernetes Deployment "name" field by adding a `Deployment{name: <regex>}` constraint to your own files). But it's not clear to me how you would do other kinds of patches.
2. Generally CUE is a turing-incomplete language, which means you cannot program. No user functions or lambdas by design. There are a number of utilities provided in the stdlib which are idempotent. It is not possible to maintain the guarantees of the language with user define functions. There are list and field comprehensions which are like a map. You can fold be simulated with comprehension. A proper fold could be added at some point.
To rephrase, how would one describe Cue type system as a generalization of a naive structural type system?
2. Not sure what you mean by 'idempotent', perhaps 'pure' or 'no side-effects'? There is plenty of non-turing complete computations that can be done with pure functions.