What is CUE? (The article seems to presume familiarity?). Edit: browser coloring settings stupidity on my end: thanks to commenter below.
There is a link to a page about it in the second paragraph
Thank you...browser settings fail on my end.
How CUE Wins (2021)
11–20 of 44 posts
Re: How CUE Wins (2021)
#12Earlier quoted context omitted.
The CUE command line tool is written in Go, and works on pretty much any operating system and architecture supported by Go, which now includes almost everything[0], so I am not sure how you came to that conclusion. If you want to use CUE as a library, you can only do it from Go at the moment. We are acutely aware of this limitation and we are investigating possible solutions. [0] https://go.dev/doc/install/source#env…
Also, the docs need a lot of work
I've found https://cuetorials.com to be useful when I can't find what I need at https://cuelang.org/docs
Re: How CUE Wins (2021)
#13Cue feels like a solution looking for a problem
Re: How CUE Wins (2021)
#14Cue feels like a solution looking for a problem
It definitely solves some problems but I don't think it is the best bang for the buck. A lot of problems are solved with annoying json/yaml, those fire and forget stuff, barely need updates. Idk, I'd love some venn diagram of all problems Cue aims to solve, and also have some notes on some part of circle (problems) that are solved by more lightweight or better tools.
Re: How CUE Wins (2021)
#15I got very into CUE for a bit but...
My hot take after all this is that it doesn't actually matter if your config language is Turing complete. Just use your regular programming language for config, I use typescript, it's great.
If for some reason you write an infinite loop in your config... you'll find out really quickly and fix it. Non-turing completeness doesn't actually solve any problems you care about, but using a crippled language does make simple things needlessly difficult.
Re: How CUE Wins (2021)
#16Anyone having used both KCL[1] and Cue? There is a comparison presented by KCL[2], but wanted to hear people's personal experience.
[1]: https://news.ycombinator.com/item?id=34144566 [2]: https://kcl-lang.io/docs/user_docs/getting-started/intro/#vs...
Re: How CUE Wins (2021)
#17I got very into CUE for a bit but... My hot take after all this is that it doesn't actually matter if your config language is Turing complete. Just use your regular programming language for config, I use typescript, it's great. If for some reason you write an infinite loop in your config... you'll find out really quickly and fix it. Non-turing completeness doesn't actually solve any problems you care about, but using…
I don't particularly care whether a language is Turing-complete or not. In the case of CUE, I like it because (a) unification is commutative, so I can define things in the most appropriate place (e.g. a company-wide repo, or project-specific, or for dev environments, etc.) and it makes no difference to the end result and (b) it has no side-effects, which avoids the temptation to e.g. open external files, or look in env vars, or download something, etc.
Re: How CUE Wins (2021)
#18Cue feels like a solution looking for a problem
It definitely solves some problems but I don't think it is the best bang for the buck. A lot of problems are solved with annoying json/yaml, those fire and forget stuff, barely need updates. Idk, I'd love some venn diagram of all problems Cue aims to solve, and also have some notes on some part of circle (problems) that are solved by more lightweight or better tools.
CUE is a superset of JSON, so the correct way to use CUE for problems that only need JSON is... to just write JSON. If you later decide to introduce CUE, then your existing files will work as-is.
Re: How CUE Wins (2021)
#19I got very into CUE for a bit but... My hot take after all this is that it doesn't actually matter if your config language is Turing complete. Just use your regular programming language for config, I use typescript, it's great. If for some reason you write an infinite loop in your config... you'll find out really quickly and fix it. Non-turing completeness doesn't actually solve any problems you care about, but using…
I don't particularly care whether a language is Turing-complete or not. In the case of CUE, I like it because (a) unification is commutative, so I can define things in the most appropriate place (e.g. a company-wide repo, or project-specific, or for dev environments, etc.) and it makes no difference to the end result and (b) it has no side-effects, which avoids the temptation to e.g. open external files, or look in e…
One big advantage of CUE being a total language is that you can always evaluate it in very different contexts. Yes, it doesn't matter whether your config is TC or not if all you do with it is configure one single program. If you have an infinite loop in your configuration instance (or if you think you have, assuming you haven't solved the halting problem) you will just fix your configuration for that specific program.
But large systems are not like this. There is no single configuration instance, configuration is pulled from all kinds of places, and each part of the system sees a different subset of configuration. And very importantly, this changes over time. The impact of a single change in some place becomes very hard to predict. Making the language total is one way we can limit the impact of configuration changes. Others that you mentioned are commutativity and the lack of side effects.
Also, being total means you can freely evaluate CUE outside other contexts than simply program configuration. For example, you can do configuration testing independently of deployment, or you can do large scale automatic refactoring, you can inspect the system in arbitrary ways, etc.
Re: How CUE Wins (2021)
#20I got very into CUE for a bit but... My hot take after all this is that it doesn't actually matter if your config language is Turing complete. Just use your regular programming language for config, I use typescript, it's great. If for some reason you write an infinite loop in your config... you'll find out really quickly and fix it. Non-turing completeness doesn't actually solve any problems you care about, but using…
An infinite loop is not the most frequent type of non-termination. Crashing is.
When your "config" fails to load halfway through its interpretation because of a KeyError, ValueError, NullPointerException, "null has no method ", you see some of the downsides of Turing-completeness.