How CUE Wins (2021) • Hacker News Board

Re: How CUE Wins (2021)

#41

Post by klodolph » Fri, Jan 13, 2023, 8:33 PM UTC

numbsafari wrote: post #27

chriswarbo wrote: post #17

Earlier quoted context omitted.

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…

You’d think, as an industry, we’d have learned that parsing an introspecting config files shouldn’t have side effects.

I think you may be overestimating how universal the lessons are.

For more complicated configs, a common approach I see is that the “config file” is a program that generates the actual configuration data. If you just need to parse and introspect the config data, you fetch the build output and parse that, which does not have side effects.

Re: How CUE Wins (2021)

#42

Post by yawnxyz » Fri, Jan 13, 2023, 8:45 PM UTC

If you've ever had to deal with REDCap (a clinical trial "CRM") and its atrocious data dictionary system, CUE makes your life much easier! Just use CUE to generate all the configs for you.

Re: How CUE Wins (2021)

#43

Post by mhsred5 » Fri, Jan 13, 2023, 9:32 PM UTC

structringtxt wrote: post #39

habitue wrote: post #15

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

At the end of the day we’re structuring syntax in a file within the constraints of some compiler or interpreter, which itself is implemented as structured text. Engineering is about keeping it simple. So I agree; we can avoid dozens of flavors of structured text (using up worker time to learn, compute cycles to use) and stick to general programming languages rather than prove how clever we can be by creating yet anot…

The problem with using a general programming language for configuration is you end up needing to use that config in different places, in different contexts, and from different languages. So, you have to marshall out and marshall in that structure to some intermediate format.

You want it to be easy for humans to edit and grok, so you find a way to represent the core parts you care about as text and cordone off the general programming language to another area.

You're successful and the number of use cases you cover grows, so the size of that config grows.

And before you know it, you've invented YAML.

Whereas, if you use Cue instead of YAML it looks pretty similar - in fact some large subset of it will be parsed correctly by a YAML parser. But the difference is with Cue you can: 1. Validate the structures in your config 2. Deduplicate by referencing other values in your config (something you can't do in JSON/YAML). 3. Use language built-ins to reduce boiler plate and repetitive text.

Re: How CUE Wins (2021)

#44

Post by link89 » Tue, Jan 17, 2023, 8:29 AM UTC

I have tried both typescript and cue-lang to generate json configuration for a while and I have to say that I prefer typescript to cue-lang, especially after deno provides native support for typescript.

I don't think Turing complete or not matters a lot for a configuration language. What really matter are the toolchain support and the ability of express complex concept or relationships. Writing typescript with VsCode is a really pleasure and its type system is powerful enough to express complicate concepts. Besides typescript has mature packages systems which cue-lang is not ready yet.

With typescript you can easily do things like reading a json configuration via HTTP and override some varibles to generate the target json file you want, which would be hard to do the same thing with cue-lang.

As a conclusion, I don't think currently cue-lang would be a good solution for configuration generation. But I do believe it would get better in the future if the community keeps working on it.