111–120 of 167 posts
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.
What if you're using multiple programming languages?
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 a…
> 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?)
InfiniteListOf = Type ->
Type & InfiniteListOf Type
IncrementingInfiniteListFrom = number ->
number & IncrementingInfiniteListFrom number+1
Earlier quoted context omitted.
Even worse, the examples are complex and incomplete.
Or make me go blacklist this project and everything to do with it (largeCapital pop >5M)
So if you add a field, you break existing code that doesn't know about the field.
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
Stop commenting on every HN post, thanks
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.
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.
What if you're using multiple programming languages?
> 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!
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.
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.
If it doesn't at least "compile" to JSON, how are we to load it into arbitrary environments?
How does this compare to jsonnet or hocon? Why would someone choose this over generating configuration files with a “scripting” language like python?
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.
The Cue docs talk about jsonnet explicitly.