Because people write code that is hard to understand. Configuration doesn't need all that. What it needs is to be provably correct and easy for someone to make predictable changes under high pressure (when prod is down). The non-terminating thing is one of the features of a turing incomplete language, not the goal. You don't want inheritance either, because it becomes hard to know where and when a value gets set (which is what helm overlay via multiple -f uses effectively is)

You speak like turning incomplete languages cannot have the control structures, tooling, and ecosystems we enjoy elsewhere, which would be the wrong assessment. I recommend you take a look at CUE to see how this can be true

The OpenAPI specs are probably better than the Go language types for k8s. They have more of the validation information and you can get at the CRDs / versions actually running in the cluster.

I am not saying that Turing incomplete languages don’t or can’t be a good fit for this task.

However there’s no reason we should rule out general purpose languages.

We have a lot of configuration based IaC and configuration tooling a la jsonnette and cue and yet these are riddled with their own problems and DX issues.

Anyways we don’t need to see eye to to eye on this but I respect your position.

In addition it is actually hard to not make a template language accidentally Turing complete. Here is an entertaining list of accidentally Turing complete things: https://beza1e1.tuxen.de/articles/accidentally_turing_comple...

> However there’s no reason we should rule out general purpose languages.

We’ve learned the hard way general purpose languages are poor for configuration at scale. I know first hand having worked on some of the larger prod infrastructures out there.

At scale, the best SRE’s out there still have trouble reasoning about the system and end up pushing bad config that takes down prod.

Languages like CUE really are different and better. CUE in particular hits the right balance for configuration of millions of lines of k8s yaml.

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