How CUE Wins (2021) • Hacker News Board

Re: How CUE Wins (2021)

#21

Post by mhsred5 » Fri, Jan 13, 2023, 3:55 PM UTC

dhuramas wrote: post #16

Anyone 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...

I've read their comparison and it really feels like word salad.

Having gone decently down the Cue rabbit hole, I feel that Cue is remarkable in being able to do everything I need it to do without looking significantly different than JSON. The validations and boiler plate reduction are fantastic. And even without inheritance, I'm confident it can represent anything I need to without having to duplicate the same thing over and over.

Re: How CUE Wins (2021)

#22

Post by marcosdumay » Fri, Jan 13, 2023, 4:00 PM UTC

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…

Hum... I do agree that totality is overrated. I never saw anybody complaining that they had to write configuration in a Turing complete language, and I can't imagine a situation where people will scratch their heads looking at typical configuration code and wondering where the infinite loop comes from.

But purity is extremely underrated. Configuration changing due to changes on the environment is a huge problem. Network dependency is kinda ok if it exists on a single place, and determinism is assured when everything works, but if it is going to exist in a single place, that place can not be every configuration file. And all the extra I/O features of your random language must not be used, what isn't a big problem, but having things around that must not be used is always a small drag.

Re: How CUE Wins (2021)

#23

Post by nine_k » Fri, Jan 13, 2023, 4:02 PM UTC

Main takeaway for me: CUE is not just a configuration language (I knew that). CUE has an ecosystem built around it, with verification tools, translators to other config languages, and conveniences like a language server and a formatter.

Also, the language is built to be modular, and many ready-made reusable parts are available, so you don't start from scratch when migrating.

Indeed it's set to win.

Re: How CUE Wins (2021)

#24

Post by 4ad » Fri, Jan 13, 2023, 4:02 PM UTC

nine_k wrote: post #23

Main takeaway for me: CUE is not just a configuration language (I knew that). CUE has an ecosystem built around it, with verification tools, translators to other config languages , and conveniences like a language server and a formatter. Also, the language is built to be modular, and many ready-made reusable parts are available, so you don't start from scratch when migrating. Indeed it's set to win.

> translators to other config languages

And from!

Re: How CUE Wins (2021)

#25

Post by nine_k » Fri, Jan 13, 2023, 4:03 PM UTC

Existenceblinks wrote: post #10

I try to find what's the definition of "wins" and looking for some mass use case by which companies. "wins" in this article seems to be "I think this is good", am I missing something?

No, it means "CUE replaces a bunch of various configs and special-case languages with itself, gradually".

Re: How CUE Wins (2021)

#26

Post by qbasic_forever » Fri, Jan 13, 2023, 4:15 PM UTC

Existenceblinks wrote: post #10

I try to find what's the definition of "wins" and looking for some mass use case by which companies. "wins" in this article seems to be "I think this is good", am I missing something?

There are a ton of semi-competing configuration languages and systems that folks are using to tame cloud system configurations (which grow to immense complexity). Cue, dhall, jsonnet, starlark, KCL, HCL, etc. are just a few options. It's very hard to pick a 'best' one though as they each have interesting strengths.

Re: How CUE Wins (2021)

#27

Post by numbsafari » Fri, Jan 13, 2023, 4:25 PM UTC

chriswarbo wrote: post #17

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…

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.

Re: How CUE Wins (2021)

#28

Post by chriswarbo » Fri, Jan 13, 2023, 4:39 PM UTC

nine_k wrote: post #20

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…

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.

Crashing is termination; the reason it's tricky is that we often treat programs as having return type "Foo" when they actually have return type more like "Foo | Stacktrace".

(Sometimes it's easier to do theoretical work by replacing crashes with infinite loops; but that's only because it's impossible to do the converse ;) )

Re: How CUE Wins (2021)

#29

Post by adamgordonbell » Fri, Jan 13, 2023, 5:48 PM UTC

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…

The sweet spot I found for CUE was when you have existing YAML, you add CUE types externally and then validate your yaml without needing to change the program. It's like a baby step towards moving beyond YAML.

I wrote up some of how to do that here: https://earthly.dev/blog/yaml-validate-and-lint-cue-lang/

Re: How CUE Wins (2021)

#30

Post by HelloNurse » Fri, Jan 13, 2023, 6:03 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.

It's the eternal opposition between taking shortcuts and doing things the easy, cool and dangerous way vs. planning and optimizing and doing things the boring, slow and cautious way.

In the specific case of configuration files, the danger is easy to underestimate because configurations are often considered a minor, easy,low value part of an application.