Live data from Hacker News

Cue – A language for defining, generating, and validating data

cuelang.org

141–150 of 167 posts

Re: Cue – A language for defining, generating, and validating data

#141
post #96
post #47

Earlier quoted context omitted.

We do indeed. XML is awful, YAML is a clusterfuck, JSON is often insufficient, and so is INI. TOML looks promising, but might not make it out of its niche. If Cue is basically a better YAML with built-in schemas, that sounds pretty good.

> XML is awful I never really understood this. This seems to be an oft repeated truism from mid 2000s with little backing it up. The only awesome thing that JSON did, was lose type information as well. In fact, the only thing that I can see that JSON brought to the table was easier editing by those who didn't have IDEs, at the expense of losing type information.

XML and especially XML schema are hugely complex and almost laughably difficult to bind to any mainstream programming language. It took Java over a decade to produce a binding that could (perhaps) handle an arbitrary schema. Types boil down to sums and products, I'm not convinced the designers of XML/XSD understood this. XML has so many overlapping concepts: elements, attributes, enumerations, choices, unions, sequences, lists, element/attribute groups, substitution groups, facets, simple types, complex types etc etc IMHO it's ad-hoc and ugly; we deserve better.

Re: Cue – A language for defining, generating, and validating data

#142
post #13

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

I am pretty sure you placed the hate on the wrong target, you probable are hating borgcfg, instead of the GCL/BCL language. Disclaimer: was borgcfg owner 2016-2019.

I had my own qualms with the language itself too. My team had very complex Borg configs, so complex they took more than a minute to evaluate. Luckily the GCL team at the time was working on a new interpreter (gclx? IIRC), which was indeed much faster (I wrote a mandelbrot PNG generator in pure GCL to prove the big speedup and convince my team that switching was worth the effort).

Unfortunately there was no formal spec of the GCL language, so the new impl was based IIRC on reverse engineering the spec from the first implementation of the interpreter. It turned out our configs hit several cases where the original behaviour was either unsound (and thus the new impl sacrificed backwards compat) or we hit a bug in the new impl.

The main problem with the language (as opposed as issues with the implementations) was that finding the root of those behaviour differences was very hard. It was very hard to follow where the variables came from. The GCL scoping rules (and lazy evaluation) were indeed very unfriendly for debugging.

This was an extreme case of a pain that was felt on a daily basis by a lot of people I've been talking to.

Re: Cue – A language for defining, generating, and validating data

#143
post #95
post #49

Earlier quoted context omitted.

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

So..why not use XML?

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

Re: Cue – A language for defining, generating, and validating data

#144
post #132

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 singl…

> 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…

[deleted]

Re: Cue – A language for defining, generating, and validating data

#145
post #112

Earlier quoted context omitted.

Recompile when config changes.

If you're going to do that, you don't need configuration at all. Just hardcode everything.

Yeah, and it is not really new either. ioquake3 did that, it had a header file for some values. If you changed them, you had to recompile the QVMs. So then we added cvars, and some values such as HP, DMG, etc. stayed in the header file. I learnt programming C by fiddling around with ioquake3 and its forks, Tremulous especially. Good times.

Re: Cue – A language for defining, generating, and validating data

#146
post #37

Earlier quoted context omitted.

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.

Someone please link to the code.

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/kube...

Re: Cue – A language for defining, generating, and validating data

#147
post #115
post #97

Earlier quoted context omitted.

Stop commenting on every HN post, thanks

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.

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

Re: Cue – A language for defining, generating, and validating data

#148
post #132

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 singl…

Some of the reasons I like the tool can't be found in the language spec. CUE (the tool) provides import facilities for existing configurations like yaml, json, openapi, protobuf or even go code into cue. this helps with adoption and time spent porting existing configs. Another feature of the CUE tool is the ability to create small tools that are able to operate on cue definition files. https://github.com/cuelang/cue/blob/master/doc/tutorial/kube...

Re: Cue – A language for defining, generating, and validating data

#149

Here is an interesting example showing what it looks like: https://github.com/cuelang/cue/blob/e5d8d09b3ba2e4f48c84a3b5... 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.

Is the language supposed to "validate"?

In this file, there is no constraint describing non-negative number or non-empty string, or ill-formed URL, or invalid number ports.

EDIT : found it in the doc : https://cuelang.org/docs/usecases/validation/

Re: Cue – A language for defining, generating, and validating data

#150
post #80

Earlier quoted context omitted.

New standards: https://xkcd.com/927/

The problem is not that there are too many configuration languages. The problem is that none of them are any good. The way to solve that is to keep trying new ones until we find one that is good.

Or the premise is a false one, that a configuration language is not the right approach. And everytime yet another such language falls flat only serves to reinforce this very point.
Post reply on HN