> My recommendation is to make your choice based on the merits of the options, rather than trying to keep up with the latest trend.
It's not a matter of keeping up with the latest trend, it's a matter of moving a whole org to a technology or project that gets killed off. There are real costs to making the wrong choice.
> If nothing else, it will make you smarter, and that will make you more conscious, and that will make you more alive.
Which is great if you're talking about a personal project but if you're setting strategy for an org or team then you need a better metric than "how alive does it make you feel."
CUE is something that can augment your existing tools. You don't have to replace them. You can adopt incrementally to add confidence where you find repeated configuration mistakes. If you want to validate your configuration with concise schemas, then you can use it like JSON Schema, even importing your existing schemas and making them readable.
CUE will make you think about the structure and taxonomy of your configuration / data. If anything, this is a good exercise that can make your code better even if you don't end up adopting CUE.
Yes, but if you move all your stuff to Cue, you've committed to it for a while. My company has tons of apps on Kubernetes: Currently around 2,200 resources totaling more than 100,000 lines of YAML. And we're not a big organization. But once migrated, even an org our size is going to find it hard to migrate to something else.
Being snarky, I'd say you won't look back if you did migrate. Again, you could just place CUE next to Yaml to validate it.
You can always write the yaml version to disk from CUE. CUE will also read and import your Yaml so that you don't have to rewrite it by hand. It would certainly be harder to migrate away from something like Starlark or Pulumi where config is wrapped in code. 3rd party tooling is much harder to write under that paradigm.
Marcel, the creator of CUE, wrote the prototype that became Borg and eventually Kubernetes. He was also on the teams that wrote the config languages for these systems. Your use case has been central to CUE's design.
> Which is great if you're talking about a personal project but if you're setting strategy for an org or team then you need a better metric than "how alive does it make you feel."
I don't think GP meant you base your strategy on "how alive Cue makes you feel". They simply meant the concepts are a good read and having read the Cue documentation before, I agree with it.
It's more satisfying to choose something with less mindshare for your own reason, than something with more mindshare for no reason of your own.
Take a look at the logic of cue: https://cuelang.org/docs/concepts/logic/
If nothing else, it will make you smarter, and that will make you more conscious, and that will make you more alive.