[barries11]

Coincidentally, I recently looked at using CUE as a config file format, but it looked like it was too syntactically complex and unwieldy for them to edit compared to, say, TOML (which is warty-but-usable) or YAML (which is incredibly complex and has too many footguns).

Also, in order to work with it and to understand why their configs weren't working beyond simple error messages or worse, a config file that is technically correct but does something they don't want. To do that, if seems like they'd have to (a) understand unification, (b) be able to find and read the spec files, (c) overcome the syntactic similarity between data and schema, (d) be able to build mental models of why the data and schema combine to cause the symptoms they have. I decided to not use it for that purpose (yet).

I _want_ something like CUE, which is why I was looking at it, so...

Does anyone here have any real-world experience using it as a config and/or data format and ingestion engine for users that are _not_ complexity-loving CS-ophiles like myself who love nothing more than a cool new way of munging data?

[mirekrusin]

You make it sound like unification / cue's model has some unnecessary complexity but the reality is that unification is very intuitive and whole model is one of the best (formalized!) ideas at _simplifying_ configs/data generation/transformation/validation.

Their docs are very approachable, consumable in single evening.

[athorax]

I like CUE a lot. We use it pretty heavily for schema enforcement of CRDs. That being said, it is pretty complex and learning to use it was anything but straight forward.

For more basic configs, I would potentially look into KCL https://www.kcl-lang.io/

It has a much simpler usage overall especially if you are only really trying to enforce some config rules.

The other alternative is to just use whatever language you are writing your software in and build a basic validator