> CUE in particular hits the right balance for configuration of millions of lines of k8s yaml.

CUE was created by the same person who wrote the Borg precursor and also worked on BCL & GCL.

I actually really like CUE. I use it kind of extensively as a YAML replacement where I can, and at my work we've done our best to integrate cue with our charts to validate the values used to invoke our charts and to unify the value space.

However there's something about a full blown general purpose language that is so much more flexible.

I don't think that the fact that people can and do write bad programs disqualifies general purpose languages from being great tools to build packages.

I am sure there is just as equally bad CUE, Jsonette, PKL, etc out there.

Other than CDK8s I don't know of other tools that have tried in this space to use general purpose languages to define their packages, and I think CDk8s uses are generally happy. Much more so than helm users at least.

I am not sure I can agree with this statement > We’ve learned the hard way general purpose languages are poor for configuration at scale

I think we've just assumed this, or seen a pulumi project we didn't like working in.

I believe and hope there will be plenty of room to experiment and innovate in this space!

The difference is in shared understanding. With tools like CUE or Starlark, you can learn one system and everyone can reason across each other's work. With imperative languages, every instance is a snowflake and creates significant mental overhead. It's the flexibility that is actually the problem for configuration. I get there is/was a trend towards general purpose languages in DevOps, but I think we are post peak on the adventure.