
Cue – A language for defining, generating, and validating data - wikibob
https://cuelang.org
======
buremba
It looks like an alternative to Jsonnet which has schema validation & strict
types. IMO, Jsonnet syntax is much simpler, it already has integration with
IDEs such as VSCode and Intellij and it has enough traction already.

Cue seems like an e2e solution so it's not only an alternative to Jsonnet, it
also removes the need of JSON Schema, OpenAPI, etc. so given that it's a 5
months old project, still has too much time to evolve and be mature.

We're heavily using Jsonnet for our data modeling ([https://github.com/rakam-
io/recipes](https://github.com/rakam-io/recipes)) and pretty happy with it. We
also have plans to add support for JSON Schema which is adopted by many of
IDEs so that VSCode makes us feel like we're writing Java, not a Jsonnet file.

Cue is Google's 6th attempt and given that Jsonnet already has traction and
works well out of the box, I would invest my time into Jsonnet at this time.

------
bhk
Okay, so I've spent some time trying to understand this, and I think it's
actually really cool, but I found the "About" and "Concepts" documents tumid
and murky.

Here is my understanding of the basic concepts:

\- It allows a schema-like set of constraints to be declared for JSON (and
therefore for YAML & TOML) in a syntax that is an extension of JSON.

\- Cue deals with types (sets of values) where JSON deals with single values.
Ordinary JSON syntax for a _primitive_ value denotes a set containing that one
value. For example, `a: 1` means that the set of possible values for `a` is
{1}. Cue calls this a concrete definition.

\- Cue provides operators for union (`|`) and intersection (`&`) of sets, and
inequalities for ranges of numbers, and so on. `1 | 2` denotes `{1, 2}`.

\- Built-in names provide the types `int`, `float`, `string`, etc.

\- Cue "struct" types look like JSON objects, associating names with sets.
Each name/value pair is a constraint, and all constraints must be met. For
example, `{a: int}` denotes "the set of objects that have a property `a` with
the value in `int`".

\- Properties can be referenced by name; this allows a property defined in one
place to be used a type (set) definition in multiple places.

\- When a name is bound more than once, the sets associated with each binding
are intersected. This means that enforcing a schema reduces to simply
combining the schema definition with the "concrete" bindings and throwing an
error when an empty set is encountered.

BTW, if I _do_ have it all wrong and what I've described above is not an
accurate description of Cue, then I think I'll have to go build what I've
described.

Some reasons I'm afraid I'm off-base:

\- What's with the lengthy discussion of lattices, and related terminology?
Sure, we can construct a lattice from the set of possible types and a "subset
of" operator, but that's another level of abstraction away from the necessary
concepts, so I don't see what value it adds.

\- The `|` operator is described as constructing a sum type, when it seems to
me it _must_ actually be a (non-discriminated) union. Elsewhere the `|`
operator is described as "computing the join", which to me would mean finding
an element in a lattice, but for this to make sense to me I have to think of
it as adding an element to the lattice (again all the lattice or poset
terminology serves only to obfuscate things).

~~~
grayrest
> What's with the lengthy discussion of lattices, and related terminology?

It's how the author thinks about the values. All the operations move a value
up (|) or down (&) the lattice and those operations are associative,
commutative, etc. Moving down past the concrete values gets you bottom, the
error value, so 1 & 2 is _|_. It fits into things like default values where
(using # for * because HN formatting doesn't do escape sequences) a: int | #1
and a: int | #1 unify to 1 because #1 & #1 = #1 but a: int | #2 added would
result in a: int because #1 & #2 = _|_ so there is no default anymore.

I don't think the extended discussion on lattices is particularly useful. A
much better intro is the tutorial [1] plus the concepts page [2]

[1]
[https://github.com/cuelang/cue/tree/master/doc/tutorial](https://github.com/cuelang/cue/tree/master/doc/tutorial)
[2]
[https://cuelang.org/docs/concepts/logic/](https://cuelang.org/docs/concepts/logic/)

The motivation is clearly to build a tool for configuring kubernetes but I see
the combination of data, validation, and order independence as being valuable
outside that use. I've definitely had projects where it'd fit. The main reason
I'd think twice is because it does add a LOT of concepts for something that
can be pretty simple on most projects.

------
noname120
Here is an interesting example showing what it looks like:
[https://github.com/cuelang/cue/blob/e5d8d09b3ba2e4f48c84a3b5...](https://github.com/cuelang/cue/blob/e5d8d09b3ba2e4f48c84a3b5da2acbf0716379bf/doc/tutorial/kubernetes/manual/services/cloud.cue)

I used the following command on the cloned repository to find it[1]:

    
    
      find . -iname '*.cue' | xargs ls -l | tr -s ' ' | cut -d ' ' -f5,9 | sort -n
    

[1] Note that 'find' has a '-printf' option which could have been used to
simplify this one-liner.

~~~
jontro
Or just search the files directly in github? Just type T and .cue

------
hestefisk
If configuration starts becoming more complex than looking up key value pairs,
why not just write it in the programming language you are using? More
languages / serialisation just adds another layer of complexity. Config as
code is actually really neat.

~~~
zeckalpha
What if you're using multiple programming languages?

~~~
prepend
Then just pick one of them. This may be simpler than introducing another
language to the project.

~~~
zeckalpha
What if you are interfacing between multiple projects? It’s not about
introducing another language, it’s about integrating pre-existing systems.

------
rudolph9
I think a better title would be "Cue: A constraint programming langue (from
some people who work[ed] at Google)".

When you consider the use of this language within a distributed system it's
pretty freaking brilliant. [https://cuelang.org/docs/concepts/logic/#the-
value-lattice](https://cuelang.org/docs/concepts/logic/#the-value-lattice)

------
fieryscribe
This might cause confusion with cuesheets, which already exist and have the
same extension:
[https://en.m.wikipedia.org/wiki/Cue_sheet_(computing)](https://en.m.wikipedia.org/wiki/Cue_sheet_\(computing\))

~~~
ylesaout
Or worst, it could be seen as a first attempt of takeover. What will be the
next targeted extension?

~~~
sdinsn
What a strange comment. Extensions aren't the property of anyone.

------
fareesh
I feel like that validation feature could theoretically save a lot of people
that occasional 1 hour of their time that was wasted because of a typo in a
config file leading to a cryptic error message.

~~~
ptest1
This is literally a feature of XML everyone complained about when JSON was the
hottest thing, though.

------
cfors
Very interesting, I can think of a lot of places where this would be useful
for managing infrastructure.

I highly recommend reading about some of the internals, it is making me
rethink a lot of how configuration should be done.

[https://cuelang.org/docs/concepts/logic/](https://cuelang.org/docs/concepts/logic/)

------
tln
Cue was discussed previously here

[https://news.ycombinator.com/item?id=20362951](https://news.ycombinator.com/item?id=20362951)

Looks like there is a nice new web site.

It seems a bit too feature laden to take off IMO.

------
flaviu2
Seems like an interesting language, but I'm very disappointed that my first
attempt to view example code took 5 clicks.

The most important part of any programming language website is a short example
snippet: put it above the fold on the front page!

~~~
preommr
Well at least you could find an example.

I couldn't find anything after like a minute of searching. Unless we're
counting the gif that slowly shows you an example project letter by letter.

~~~
evolve2k
Someone please link to the code.

~~~
xinau
The website is under active development at the moment and their are incomplete
parts. For the code links please take a look at the following tutorial on
GitHub at the moment.

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

* [https://github.com/cuelang/cue/blob/master/doc/tutorial/kube...](https://github.com/cuelang/cue/blob/master/doc/tutorial/kubernetes/README.md)

------
carapace
> A key thing that sets CUE apart from its peer languages is that it merges
> types and values into a single concept. Whereas in most languages types and
> values are strictly distinct, CUE orders them in a single hierarchy (a
> lattice, to be precise).

That's cool!

~~~
jonathanyc
In TypeScript, an upper bound of “foo” and 5 is any. But I wonder what a lower
bound of those two is supposed to be in Cue.

~~~
zellyn
I can’t keep upper and lower straight, but `“foo” | 5` would allow either
“foo” or 5, and `”foo” & 5` would be “bottom” (also spelled “_|_”, essentially
an error)

------
wlib
I'm feeling both really pissed and validated right now. I thought this was
going to just be a normal thoughtless config language that would only be
successful as a Google project. Then I looked at the theoretical basis page. I
have no formal proof about this, but I've been talking about this type of a
type system with my parents and high school CS teacher for a while now! My
idea sounds like this: a value is simply an actual binary string. The "type"
that classifies any data is described as a formal grammar, where the binary
string is a formal language. If the language can parse a given binary value
with the formal grammar, that value is an element of the set (type). This
naturally leads to a structural type system which can be described using
existing set theory and implemented using existing parsers and formal language
theory. Of course, this leads to type -> type functions which describe
dependent and refinement types naturally. It's great to see this idea being
broadcast on the front page here, as I can see it very clearly as a superior
type system. I'm really regretting not writing a formal article about it
sooner!

~~~
uryga
> Of course, this leads to type -> type functions which describe dependent and
> refinement types naturally.

could you expand on this? i don't understand how you get this from grammars.

(on a side note, i think that dependent types usually mean you can write
functions from values to types, not type -> type?)

~~~
wlib
Yes, I mistyped that bit. I meant to say that because types (as a grammar) are
values, they can be inputs and outputs of functions. The functions can fill in
the hole that dependent/refinement types fill, by taking context into account
(the grammars which describe simple types being context free). Type -> Type
fill in for type constructors like this infinite list:

    
    
      InfiniteListOf = Type ->
        Type & InfiniteListOf Type
    

That function just morphs a simple grammar into another grammar. Imagine now
if we could calculate something in between:

    
    
      IncrementingInfiniteListFrom = number ->
        number & IncrementingInfiniteListFrom number+1
    

That's where the dependent types come in, naturally.

------
sciyoshi
Seems really interesting after a quick read-through. Specs that allow range-
based validation look useful, and the structural declarations also feel like
they'll help reduce a lot of boilerplate and repetition. I wonder how this
compares with Dhall and Jsonnet, both of which I've been looking into as a
safer alternative to templated YAML. With Google putting its weight behind
this I'm curious if it'll start finding its way into K8s.

~~~
mixmastamyk
A safer yaml:

[https://hitchdev.com/strictyaml/](https://hitchdev.com/strictyaml/)

~~~
preommr
I am really curious why people are downvoting this.

I've always thought that a more restrictive and simpler version of yaml would
be a good alternative.

~~~
mixmastamyk
Folks upset at the sibling comment weren't here at the time. The reaction was
swiftly negative, and there are few charitable reasons to be found for that.

------
jonbronson
You'd think they'd make it easier to quickly seem examples of the language.

------
nikhilsimha
How does this compare to jsonnet or hocon? Why would someone choose this over
generating configuration files with a “scripting” language like python?

~~~
atombender
CUE improves in Jsonnet in primarily two areas, I think: Making composition
better (it's order-independent and therefore consistent), and adding schemas.

Both Jsonnet and CUE have their origin in GCL internally at Google. Jsonnet is
basically GCL, as I understand it. But CUE is a whole new thing.

~~~
zellyn
jsonnet is basically GCL, but after like five failed attempts to rewrite,
replace, or fix GCL, which included creating a formal semantics of GCL
pointing out all the problems. I believe there was a final successful attempt
to fix it.

The Cue docs talk about jsonnet explicitly.

------
aledalgrande
TIL how to use cat with STDIN.

------
slifin
A lot of these systems ignore the querying side of a schema i.e. in graphql
you can define a schema then query only certain parts of the schema so only
parts of the schema are enforced at runtime

------
devj
Would like to know more on how its a good fit for database schemas? Does
anybody here use any DSLs for database schemas? If yes, what and why?

------
billfruit
Does it sport working on binary data, it would be a cool thing to have in some
applications, to validate conditions on binary data.

------
make3
my time at Google has made me hate GCL so much.

~~~
saulrh
I was going to say, this looks a lot like GCL. Dynamic scope, recursive lookup
in parent scopes, templates [1], everything. GCL is neat and all, but I'd
almost rather write my job configs by building thin python or lisp scripts to
emit json or protos.

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

~~~
wstrange
AFAIK, cue is written by the author (or one of them?) of GCL, and purports to
fix a lot of what is wrong with it.

------
siempreb
The syntax looks a lot like Coffeescript, which I use for defining and
generating data.

------
Animats
Cute. Is there something that takes in Cue and makes a GUI editor for the
format?

~~~
michaelmrose
Wouldn't the optimal one be a mode for your editor of choice?

~~~
Animats
I mean a form, with blanks and pulldowns. There's enough info in Cue to
generate one. Not just a syntax checker that tells you that you got it wrong.

~~~
michaelmrose
I don't think a gui to work with cue files is a good substitute for a gui for
regular users to configure whatever you are configuring because its unlikely
to be able to define valid data to the same degree as an actual app.

If its for a technical individual to configure your software I don't know that
such a gui would be superior to your favorite editor.

------
mohaba
Welcome to kubernetes new configuration language!

------
m0zg
They should just foist BCL and Borgmon upon the gullible masses. All cloud
development will be set back years while people (try to) figure it all out.

~~~
bt848
We used to joke that open-sourcing Borgmon would be an industry-disabling
move, but Prometheus is very popular which just proves there's a lot of people
with poor taste in software.

FWIW Piccolo has also leaked into the industry in the form of Pystachio.

~~~
xnxn
Gullible mass member here. What's better than Prometheus?

~~~
bt848
Eating glass.

------
summerlight
The post title is misleading. This is a more of 20% project, not an officially
Google supported one.

~~~
Despegar
There's no difference.

~~~
joatmon-snoo
There is a large difference between battle-tested tech maintained by a
properly staffed team and a proof of concept built by someone in their spare
time.

The title certainly made me think that it was the former, even though it's the
latter.

~~~
smt88
> _maintained by a properly staffed team_

This seems to describe very few Google products. Almost daily, I have the
following thought: "Has anyone at Google actually even used this product?"

(Most often with Assistant, but definitely with other products, too)

~~~
lonelappde
Just because you don't like doesn't mean it's not built and supported by a
large team following some VP or PM vision. Boondoggles cost a lot of
resources.

~~~
smt88
Perhaps I have a different definition of "maintained" than Google does. For
me, it means that it's not just online, but also has bugs regularly fixed and
features added.

Most Google services (off the top of my head: Voice, Talk, Reminders) seem to
reach v1 and then stop dead in their tracks. They're online, but that's it.
Thousands of people request fixes or features, and they go completely unheard.

Google employees on HN have confirmed this, saying that the company rewards
new products that drive ads, but not the work involved in improving and
maintaining existing products. That explains why Google's released the
following products for messaging, and none has been amazing: Talk, Hangouts,
Voice, Wave, Allo, Hangouts Chat, and Messages/RCS.

Most of these overlapped at some point, and if you've used any of them, you
wouldn't describe them as "maintained". They're more like "abandoned without
publicly announcing anything".

If there's a VP or PM vision anywhere at Google that lasts for more than a
year, I'd love to know what it is. It seems like a company with a thousand
committees and no real creative leadership.

------
koston
How is this better than yaml?

~~~
mikl
Less footguns, built-in validation, strong types. Me gusta.

~~~
ptest1
So..why not use XML?

~~~
tempo33
Because while XML has types and schemas, the actual implementation and
ergonomics is absolute garbage. Those things matter to intelligent people.

------
thesuperbigfrog
Obligatory:
[https://imgs.xkcd.com/comics/standards.png](https://imgs.xkcd.com/comics/standards.png)

------
underwater
The tl;dr is buried deep in the docs

> CUE is an extension of JSON. This improves familiarity and makes it easy to
> get going quickly.

> In its simplest use case, CUE can substitute for a more pleasant way to
> write JSON.

~~~
nabdab
So it’s a google branded yaml?

Let’s raise a glass to our blue eyed comrades who’ll adopt this fully, only
for google to decide in 2-3 years to completely and aggressively kill it again
for no apparent reason.

~~~
dvtrn
Pardon for slamming my ignorance down on the table here: I know Google has a
tendency of killing _products_ but I’m not familiar with many of their
engineering tooling being similarly sunset with comparable frequency.

Any named examples? I’m sure there are-and likely they just elude me at
present, maybe seeing their names will jog the memory probably?

~~~
mirekrusin
jsonnet? :)

~~~
zellyn
The jsonnet mailing list still has activity. Is the project dead?

------
etxm
Feels like an also crappy jsonnet

------
esotericn
Well, it doesn't look very backwards compatible to me ;)

[https://en.wikipedia.org/wiki/Cue_sheet_(computing)](https://en.wikipedia.org/wiki/Cue_sheet_\(computing\))

------
samstave
Ill prolly get downvoted for this:

What i want to see, is a company which will provide as a service, basically
devops deployment, monitoring and provisioning regardless of the cloud
provider.

Such that i can say “deploy this” and it will eval, track and monitor the cost
of the deployment across aws, azure, gcp, etc and i can click controls to
see/kil/scale wherever...

Thus, i dont care about cloud provider deployment language, etc...

~~~
segmondy
checkout [https://apex.sh/up/](https://apex.sh/up/)

------
breck
Disclosure: I work on Tree Notation.

If the authors would like to discuss how Tree Notation may be a better syntax
for this language, please feel free to get in touch: breck7@gmail.com or
yunits@hawaii.edu.

Here is a demonstration of what a Tree Language for config files could look
like:
[https://treenotation.org/designer/#standard%20config](https://treenotation.org/designer/#standard%20config)

~~~
ptest1
Stop commenting on every HN post, thanks

~~~
breck
Fact: I've commented on fewer than 1% of HN posts today alone.

Fact: my post is very relevant to the OP and I'm offering to help them.

Fact: I've been a member of this site for over 12 years, and never comment on
a post unless I think it adds value to the discussion or would be helper to
the parent.

~~~
DannyBee
Fact: What you wrote was essentially a private, directed comment that should
have been a private email, and added literally nothing to the discussion.

~~~
breck
> should have been a private email

That's a good suggestion. I didn't think of that. But thinking about it, I
guess I don't want to bother the OPs inbox. If they are interested, they can
get in touch.

> added literally nothing to the discussion.

I disagree. When I post a new language, and someone shares a link to a related
language, those are often the most valuable comments.

Validating, defining, using data: sound like things Tree Notation syntax is
perfect for. Cue's semantics are great, and presentation and execution, I just
think potentially a syntax switch is worth exploring. I understand the
strategy to be able to parse JSON as cue, and that's probably the way to go
for now, but in the future Tree Notation syntax might offer compelling
advantages.

