
The CUE Data Constraint Language - devj
https://github.com/cuelang/cue
======
justicezyx
Huge congrats to mpvl@ for the final release of CUE on github.

mpvl@ is the main author of borgcfg and one of the two designers of BCL (borg
config language). I was maintaining borgcfg 2017-2019, and naturally had
occasions to chat with him. I was fortunate to learn the existence of CUE a
while ago, and was convinced that its theoretical foundation is solid. That
foundation is simply not there in most config languages. CUE (along with
Kustomize) appears to me to be the 2 major new ideas of addressing the flaws
in BCL, and other template/inheritance-based config languages.

I am very eager to see how the community and industry react to CUE.

~~~
purpleidea
CUE itself is rather cool. The fact that people think kube and templating YAML
is the answer is very uncool. CUE is an okay solution around a bad problem.

Best to avoid this kube+YAML nightmare and go with something with a solid core
design. No the Borg paper had no real convince logic in it.

~~~
justicezyx
> No the Borg paper had no real convince logic in it.

What does this mean?

Are you saying that Borg paper [1] has some arguments for using configuration?

It sounds like you have a good insight around the config mess in
infrastructure management.

[1]
[https://ai.google/research/pubs/pub43438](https://ai.google/research/pubs/pub43438)

------
shurcooL
It’s interesting for me to see a project made mostly by 1 person that happens
to be employed by Google described as “by Google”. [1] Not that there’s no
truth to it, just that the reality is much more nuanced than a simple phrase
can capture.

[1]
[https://github.com/cuelang/cue/graphs/contributors](https://github.com/cuelang/cue/graphs/contributors)

~~~
gravypod
It looks like Google owns the project and that, to contribute, you have to
turn over copyrights [0]. I think the ownership makes it "by Google" more than
employing the main dev.

[0] -
[https://cue.googlesource.com/cue/+/HEAD/doc/contribute.md#st...](https://cue.googlesource.com/cue/+/HEAD/doc/contribute.md#step-1_contributor-
license-agreement)

~~~
jsolson
That's common to most projects released by Googlers. Options are either a
getting the IP officially assigned over to yourself or releasing it under a
Google copyright with a CLA:
[https://opensource.google.com/docs/creating/](https://opensource.google.com/docs/creating/)

The latter is lower friction, in my opinion.

This is especially common for "personal" projects that people end up working
on or using on the clock.

I don't know if this was the case with Cue specifically (this is the first
I've heard of the project, but less boilerplate in my JSON has some appeal).

------
leshow
I like dhall better than this, [https://dhall-lang.org/](https://dhall-
lang.org/)

~~~
svnpenn
I just cant understand how a sane person would use syntax like this:

    
    
        { home       = "/home/bill"
        , privateKey = "/home/bill/id_ed25519"
        , publicKey  = "/home/blil/id_ed25519.pub"
        }
    

and call it "human friendly" with a straight face. just use the normal syntax:

    
    
        {
           home = "/home/bill",
           privateKey = "/home/bill/id_ed25519",
           publicKey  = "/home/blil/id_ed25519.pub"
        }
    

advocates will say, "well you can delete the last line without it breaking".
ok. but what about the first line? youve just moved the problem. its
frustrating because this is a solved problem. either remove comma altogether
(YAML) or allow trailing comma (Python). Dont do this weird leading comma
stuff. Its just living in denial.

~~~
swsieber
Hmm... the advocates I've run into say that you can add a newline with out
modifying the old last line. And that one makes sense, since you tend to (or
at least I tend to) add things at the end.

~~~
saagarjha
That's why every well-designed language lets you put an extra commas on the
last line.

------
thdxr
We've been using Google's jsonnet with k8s and it's been a life saver. Think
it works pretty well so wondering what gapes they're trying to address with
Cue

~~~
wstrange
This issue is a good comparison of the two approaches:

[https://github.com/cuelang/cue/issues/33](https://github.com/cuelang/cue/issues/33)

------
oweiler
The JSON sugar way too much for me. See folding as an example

[https://github.com/cuelang/cue/blob/master/doc/tutorial/basi...](https://github.com/cuelang/cue/blob/master/doc/tutorial/basics/fold.md)

~~~
nikolay
True. I'd rather have dots instead of spaces.

~~~
dalore
Exactly, now how would you do a key that contained spaces?

~~~
ithkuil
How would you do a key that contains a dot? :-)

------
jefftk
I found paging through the tutorial a helpful way to understand what it does:
[https://cue.googlesource.com/cue/+/HEAD/doc/tutorial/basics/...](https://cue.googlesource.com/cue/+/HEAD/doc/tutorial/basics/json.md)

------
parhamn
There are quite a few of these things (Dahl, Jsonnet, etc). and I've always
thought it would be impossible to get a large enough team to learn them.

At a pervious organization I worked I wrote a Kubernetes manager (docker build
+ kube config generation + blue/green deploy) that was essentially TOML +
Jinja (we we're a python shop). A django + pg + redis app would look like [1].

[1]
[https://gist.github.com/pnegahdar/1e90f42c1686009e1ff9392b79...](https://gist.github.com/pnegahdar/1e90f42c1686009e1ff9392b797a6ed5)

There were definitely some limitations to doing this (some good, like reduced
kubernetes surface) but in the end I think we got a large percent of the team
writing kubernetes configs through cargo-culting while having generally sane
defaults, environment isolation, etc.

I wonder how organizations get people to use these things in a broad way? I'd
still be hesitant to write what was described above in something like jsonnet
even though it would be much more semantically correct -- I can't imagine
getting anyone outside of the ops team to use it!

Generally though, TOML works really well with templating languages (jinja,
golang templates, etc) if you include some helper funcs. You can even pass the
toml to itself on rendering til you hit a fixed point for references and such.

------
wodenokoto
Which of all the links will show a simple example of why one wants to store
configurations in a constraint language?

~~~
deckar01
I think it is mostly about being able to declare the config schema in the same
language. You can declare a base config file with types instead of values that
has to be extended. The parser will validate the types and insert defaults
when it is merging the configs. It also has some nice features to avoid
duplication and boilerplate.

References:
[https://github.com/cuelang/cue/blob/master/doc/tutorial/basi...](https://github.com/cuelang/cue/blob/master/doc/tutorial/basics/scopes.md)

Disjunctions:
[https://github.com/cuelang/cue/blob/master/doc/tutorial/basi...](https://github.com/cuelang/cue/blob/master/doc/tutorial/basics/disjunctions.md)

Templates:
[https://github.com/cuelang/cue/blob/master/doc/tutorial/basi...](https://github.com/cuelang/cue/blob/master/doc/tutorial/basics/templates.md)

------
sansnomme
At this rate we might as well just use Prolog for configuration.

~~~
nikolay
You don't recall Marelle?
[https://news.ycombinator.com/item?id=6701362](https://news.ycombinator.com/item?id=6701362)

------
mickeypi
Unfortunately it inherits JSON’s lack of support for dates.

~~~
tlb
What’s the use case for dates in a config language?

crontab is an example that comes to mind, but it uses its own system of date-
time patterns. Javascript Date objects wouldnt be suitable.

~~~
jsnell
Date arithmetic, parsing and formatting are very useful in config languages.
Maybe your configs needs to express that when a program is run, the input
should be read from a log file from two days ago named like
/foo/bar/2019/07/02/access.log. That requires knowing what the current time
is, computing what the time was two days ago, and formatting it in an
arbitrary custom format (in this case YYYY/MM/DD).

That doesn't necessarily mean that the language needs dates as a first class
data type with a literal syntax etc.

------
AlphaSite
This seems like one of those languages which is designed to be easy to write
and easy to parse, but reader ambiguity appears to have been left on the
wayside.

~~~
ithkuil
One of the nice things is that all the merging rules are commutative
associative and idempotent. Not subtly changing the semantics when you move
fields around (willingly or unexpectedly during e.g. a git merge operation) is
a huge plus for me. From the lexical point of view, I don't see the usual red
flags that plague yaml (where v1.0 is a string but 1.0 is a number

------
ytklx
Shameless plug: A JSON-like configuration language with considerably less
features, no magic and no ambiguity:
[https://github.com/yuce/jacl](https://github.com/yuce/jacl)

------
redder2
I like YAML and TOML for fro configs. Never liked JSON at all. There are some
nice sugars when in comes to quotes, commas that annoy me in JSON but it seems
way to complicated and filled with tons of features to learn when here are
established config languages that work and have a huge future set you just do
not need to use at all like YAML.

Also its looks ugly having even have roon in curlies. Have not look at
everything, I am sure Google has its use for this but I think its to much for
just configs. And if someone can point why they not just use YAML I would be
interested.

~~~
ithkuil
If you can get away with just a static config file then pick toml or whatever
and live a happy life (less so with yaml because it has some traps like when
type autodetection fails spectacularly, try "a: yes".

Sometimes you might have a legitimate reason to build complex systems out of
configs (cloud formation templates, kubernetes, terraform). In that case you
might need a bridle to enforce some structure, to keep common things common,
and to ensure that variants (such as testing and staging environments) can be
expressed in a robust way.

------
syn0byte
We need to stop using the phrase "don't reinvent the wheel" and start using
the phrase "don't reinvent the hammer" CS/IT seems to have some weird
solipsistic fetish for tooling in some dogmatic quest for abstraction.

I'm sure there is great for someone somewhere doing something but I just see
another turtle in the stack...

~~~
root_axis
So don't use it? Why do so many people on this site complain about people
making stuff? It's really odd. Just don't use it.

~~~
stuffbyspencer
I agree with this. It's sorta strange to me that the above poster is aware
enough to mention that this "might be useful to someone", but then dogs on it.

If you don't have a need for it, perhaps consider it is not for you.

------
nikolay
Another configuration language, which, I think, is pretty clean and down to
Earth: [https://github.com/zaphar/ucg](https://github.com/zaphar/ucg)

------
nikolay
Ewww. Raw strings are yucky! "_|_" is just as terrible.

------
unixhero
Does this have any relation with .cue sheets used to describe data structures
within .bin/.iso file dumps of data CDs, audio CDs, VCDs, SVCD, DVDs and Blu-
ray's???

~~~
unixhero
Edit: No it does not. The cue format I am referring to here was published by
CDRWIN developers. Later also used by ExactAudioCopy, Ahead Nero and all other
relevant CD-R burning software at the time, and currently as well.

------
gaze
What is it and what does it do? Examples for how you'd apply this in
production? Anything?

------
billfruit
I wish if something similar was available for binary data, im not aware of
any.

------
avmich
How does it compare with ProtoBuffer?

~~~
rockwotj
Protobufs are a data serialization format. Mostly for taking typed data and be
able to parse and write to bytes.

This is something that could generate protobuf values, as you can have
expressions and such. Really it does more than protobuf and doesn't handle
serialization. It's main use seems to be a config language

------
iddan
I needed this for so long. Looks

