My initial comment was very vague and I'm glad to see others have replied to fill in the gaps. If your service/system has a sufficiently large configuration spa

My initial comment was very vague and I'm glad to see others have replied to fill in the gaps. If your service/system has a sufficiently large configuration space, like say, Kubernetes, then a typed configuration language can greatly improve the development experience by spotting errors early on. You get a very fast feedback loop that you set the wrong value for some config option before attempting to deploy the change. Different services will give you appropriate feedback about wrong config options but that is sometimes a few steps removed from your development environment e.g. You might find out after you push a PR and CI/CD fails or after you merge the PR even. The type system also has great second order benefits like allowing us to build an language server protocol implementation for CUE that has rich diagnostics, auto-complete, jump to definition, rename symbol features. Something that cannot be done _as well_ effectively in untyped languages. I'm still scratching the surface. CUE does more than add types to config and I would encourage you to dig into it if you have spare time. By virtue of providing a great type system, it also manages to reduce boilerplate as yet another second order benefit. Boilerplate reduction is something where tools like Jsonnet attack as a primary goal but over enough time you're back at having seas of untyped config and indirection that are hard to navigate or contribute to and you're back at square one.