[peefy]

Multiple configuration merging strategies do not imply inconsistency or uncertainty, nor do they mean that one file can overwrite or patch another.

KCL also provides a certain degree of immutability, such as ensuring that exported variables are immutable and that configurations in a file cannot be modified. You can only import it and use it to generate new configurations.

In addition, in the cloud native field such as Kubernetes, configuration merging operations can be seen everywhere, such as the built-in JsonMergePatch strategy, Kustomize, and multiple environment configurations for developers. You can find similar corresponding features in KCL.

In fact, KCL also has the idempotent merge operation of cuelang, and languages such as jsonnet, pkl, Nickel also have certain configuration merge capabilities. Only cuelang strictly follows the idempotency of merging, which to some extent limits its use and understanding.

[from-nibly]

yeah, just because people are doing it doesn't mean it's good. You need to have the strictness of cuelang. But I recognize that KCL will probably win overall cause it's shiny and easy to get started with. But this will cause a LOT of problems for everyone as it already does, with things like json merge patch etc.