7 ms·

How CUE Wins (2021)

43 points by ahamez 4y ago

Kinrany 4y ago
I think CUE looks great, but right now it's losing because it can only be installed as a package for Go, MacOS and Arch.
- 4ad 4y ago
  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#environment https://go.dev/doc/install/source#environment
  - lokar 4y ago
    Also, the docs need a lot of work
    - 4ad 4y ago
      We are painfully aware of this, we are rewriting and improving the documentation as we speak and we are also working on a new web site.
    - chriswarbo 4y ago
      I've found https://cuetorials.com https://cuetorials.com to be useful when I can't find what I need at https://cuelang.org/docs https://cuelang.org/docs
  - Kinrany 4y ago
    Having to install binary manually is extra friction: you can't rely on a tool to manage it for you, you have to have a place for storing them, you have to remember where it is if you want to delete it.
- chriswarbo 4y ago
  It's in Nixpkgs, so you can use it anywhere that's supported (any Linux distro, macOS, WSL, etc.)
- corysama 4y ago
  It's a single, standalone binary executable for each platform.
jjtheblunt 4y ago
What is CUE? (The article seems to presume familiarity?). Edit: browser coloring settings stupidity on my end: thanks to commenter below.
- selbyk 4y ago
  There is a link to a page about it in the second paragraph
  - jjtheblunt 4y ago
    Thank you...browser settings fail on my end.
chriswarbo 4y ago
I've been gradually introducing CUE at my workplace. So far I've used it to generate AWS CloudFormation templates, GitHub Actions workflows, and OCI container configs. I'm also using it in git pre-commit hooks to validate files against existing jsonschemas.
Existenceblinks 4y ago
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?
- nine_k 4y ago
  No, it means "CUE replaces a bunch of various configs and special-case languages with itself, gradually".
- qbasic_forever 4y ago
  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.
mountainriver 4y ago
Cue feels like a solution looking for a problem
- Existenceblinks 4y ago
  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.
  - chriswarbo 4y ago
    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.
habitue 4y ago
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 a crippled language does make simple things needlessly difficult.
- chriswarbo 4y ago
  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.
  - 4ad 4y ago
    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.
  - numbsafari 4y ago
dhuramas 4y ago
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 https://news.ycombinator.com/item?id=34144566 [2]: https://kcl-lang.io/docs/user_docs/getting-started/intro/#vs-cue https://kcl-lang.io/docs/user_docs/getting-started/intro/#vs...
- mhsred5 4y ago
  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.
nine_k 4y ago
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.
- 4ad 4y ago
  > translators to other config languages And from!
- structringtxt 4y ago
  Go, Python, and every other known programming language have ecosystems, with syntax generators, validators, and SDKs for most APIs. Best part is I can hire people today who know how to use them. AWS SDK for Go has snippets that just work right in the docs. Writing some logic like “if attempting to use AWS types a, b, c, or send values outside this regex, error” is not that hard. Having learned Puppet, Chef, Ansible, and having zero use for them day-to-day in the current reality of “beam API params”, a problem specific DSL seems like a dubious proposition.
buremba 4y ago
The friction is still too much IMO. While I love the configuration languages, I still find myself writing YAML because it's much simpler. The tooling support is getting there but I don't understand why these tools introduce their own syntax and type system rather than being a superset of YML or JSON and using JSON Schema as the type system. I was an evangelist for Jsonnet but somehow it didn't get enough traction over time. I blame the lack of type support and integrations with the IDEs such as VSCode. I regularly check the VSCode & Intellij support for CUE as well but the support is still at the level of syntax highlighing, not more than that, which is sad. Nowadays, I use VSCode with YML extensions (anchor, etc.) and use JSON Schema to validate the YML in the IDE with its language server. It's far from perfect but easy to iterate and portable.
- 4ad 4y ago
  > I don't understand why these tools introduce their own syntax and type system rather than being a superset of YML or JSON CUE is a superset of JSON.
  - buremba 4y ago
    Same as Jsonnet but it's only a small part of the picture. For someone who use JSON, I expect the adoption of CUE to be incremental but in reality I need to use CUE's own syntax to get the value out of it. Jsonnet was was closer to to the mindset that I have with that respect. Some context: https://github.com/google/jsonnet/issues/605#issuecomment-728457371 https://github.com/google/jsonnet/issues/605#issuecomment-72...
einpoklum 4y ago
tl;dr: 1. CUE is a configuration language the author is promoting. 2. Author says CUE wins by becoming ubiquitous. :-(
yawnxyz 4y ago
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.
link89 4y ago
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.

How CUE Wins (2021)

43 points by ahamez 4y ago

I think CUE looks great, but right now it's losing because it can only be installed as a package for Go, MacOS and Arch.

4ad 4y ago
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#environment https://go.dev/doc/install/source#environment
- lokar 4y ago
  Also, the docs need a lot of work
  - 4ad 4y ago
    We are painfully aware of this, we are rewriting and improving the documentation as we speak and we are also working on a new web site.
  - chriswarbo 4y ago
    I've found https://cuetorials.com https://cuetorials.com to be useful when I can't find what I need at https://cuelang.org/docs https://cuelang.org/docs
- Kinrany 4y ago
  Having to install binary manually is extra friction: you can't rely on a tool to manage it for you, you have to have a place for storing them, you have to remember where it is if you want to delete it.
chriswarbo 4y ago
It's in Nixpkgs, so you can use it anywhere that's supported (any Linux distro, macOS, WSL, etc.)
corysama 4y ago
It's a single, standalone binary executable for each platform.

jjtheblunt 4y ago

What is CUE? (The article seems to presume familiarity?). Edit: browser coloring settings stupidity on my end: thanks to commenter below.

selbyk 4y ago
There is a link to a page about it in the second paragraph
- jjtheblunt 4y ago
  Thank you...browser settings fail on my end.

chriswarbo 4y ago

I've been gradually introducing CUE at my workplace. So far I've used it to generate AWS CloudFormation templates, GitHub Actions workflows, and OCI container configs. I'm also using it in git pre-commit hooks to validate files against existing jsonschemas.

Existenceblinks 4y ago

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?

nine_k 4y ago
No, it means "CUE replaces a bunch of various configs and special-case languages with itself, gradually".
qbasic_forever 4y ago
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.

mountainriver 4y ago

Cue feels like a solution looking for a problem

Existenceblinks 4y ago
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.
- chriswarbo 4y ago
  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.

habitue 4y ago

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 a crippled language does make simple things needlessly difficult.

chriswarbo 4y ago
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.
- 4ad 4y ago
  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.
- numbsafari 4y ago

dhuramas 4y ago

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 https://news.ycombinator.com/item?id=34144566 [2]: https://kcl-lang.io/docs/user_docs/getting-started/intro/#vs-cue https://kcl-lang.io/docs/user_docs/getting-started/intro/#vs...

mhsred5 4y ago
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.

nine_k 4y ago

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.

4ad 4y ago
> translators to other config languages And from!
structringtxt 4y ago
Go, Python, and every other known programming language have ecosystems, with syntax generators, validators, and SDKs for most APIs. Best part is I can hire people today who know how to use them. AWS SDK for Go has snippets that just work right in the docs. Writing some logic like “if attempting to use AWS types a, b, c, or send values outside this regex, error” is not that hard. Having learned Puppet, Chef, Ansible, and having zero use for them day-to-day in the current reality of “beam API params”, a problem specific DSL seems like a dubious proposition.

buremba 4y ago

The friction is still too much IMO. While I love the configuration languages, I still find myself writing YAML because it's much simpler. The tooling support is getting there but I don't understand why these tools introduce their own syntax and type system rather than being a superset of YML or JSON and using JSON Schema as the type system. I was an evangelist for Jsonnet but somehow it didn't get enough traction over time. I blame the lack of type support and integrations with the IDEs such as VSCode. I regularly check the VSCode & Intellij support for CUE as well but the support is still at the level of syntax highlighing, not more than that, which is sad. Nowadays, I use VSCode with YML extensions (anchor, etc.) and use JSON Schema to validate the YML in the IDE with its language server. It's far from perfect but easy to iterate and portable.

4ad 4y ago
> I don't understand why these tools introduce their own syntax and type system rather than being a superset of YML or JSON CUE is a superset of JSON.
- buremba 4y ago
  Same as Jsonnet but it's only a small part of the picture. For someone who use JSON, I expect the adoption of CUE to be incremental but in reality I need to use CUE's own syntax to get the value out of it. Jsonnet was was closer to to the mindset that I have with that respect. Some context: https://github.com/google/jsonnet/issues/605#issuecomment-728457371 https://github.com/google/jsonnet/issues/605#issuecomment-72...

einpoklum 4y ago

tl;dr: 1. CUE is a configuration language the author is promoting. 2. Author says CUE wins by becoming ubiquitous. :-(

yawnxyz 4y ago

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.

link89 4y ago

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.