Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How CUE Wins (2021)

blog.cedriccharly.com

Post reply on HN
Print view View original

31–40 of 44 posts

Re: How CUE Wins (2021)

#31

Post by dustbitying »

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.

given your argument, it seems your gripe is with object orientation rather than with turing-completeness.

Re: How CUE Wins (2021)

#32

Post by buremba »

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.

Re: How CUE Wins (2021)

#33

Post by nine_k »

dustbitying wrote: post #31
nine_k wrote: post #20

Earlier quoted context omitted.

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.

given your argument, it seems your gripe is with object orientation rather than with turing-completeness.

Rather, with dynamic languages used for config files. I could use Lisp or Lua for the example, but they are not as recognizable in this role.

Re: How CUE Wins (2021)

#34

Post by 4ad »

buremba wrote: post #32

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

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

Re: How CUE Wins (2021)

#35

Post by buremba »

4ad wrote: post #34
buremba wrote: post #32

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

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

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

Re: How CUE Wins (2021)

#37

Post by Kinrany »

4ad wrote: post #3
Kinrany wrote: post #2

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.

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…

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.

Re: How CUE Wins (2021)

#39

Post by structringtxt »

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 another tokenizer, parser, writer with some hand wavy, tangential connection to mathematical concepts.

Re: How CUE Wins (2021)

#40

Post by structringtxt »

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.

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.

Post reply on HN