一种合理的配置语言
配置文件正越来越从 JSON 或 YAML 这类简单数据格式演变为完整的、甚至有时是图灵完备的语言，这也引发了人们对“配置”和“代码”边界应当划在哪里的讨论。评论者权衡了专用配置语言（如 HCL、Dhall、Jsonnet、Nix、基于 Lua 的方案，以及新提出的 RCL）与复用通用编程语言之间的取舍，重点关注安全性、可读性、工具链以及跨语言互操作性。许多人主张使用受限、无副作用、声明式的语言，同时仍能表达复用和逻辑；而另一些人则认为，专有方案的不断涌现恰恰说明，复杂系统的配置仍然是一个尚未解决、且对运维至关重要的问题。
配置复杂度不断升级
- 许多系统最初使用简单格式（INI/JSON/YAML），随后逐步加入覆盖层、模板、表达式，最终走向完整计算。
- 对于部署和基础设施工具来说，这条“兔子洞”几乎被视为不可避免；每个生态系统都会重新发明类似的工作流/配置引擎。
- 有人认为，大多数软件实际上止步于层级参数；只有基础设施/工作流系统才会深入配置复杂度。
为什么一定要有专门的配置语言？
- 怀疑者会问，为什么不直接使用现有编程语言加数据格式。
- 支持者回应说，配置有独特需求：受限的能力、更易上手、与语言无关的互操作性，以及更安全的处理方式（例如无需执行任意代码即可对配置进行静态分析）。
- 还有社会层面的因素：很多基础设施用户并不想成为真正的程序员，但仍然需要某种抽象和复用。
图灵完备性、安全性与求值
- 一些评论反对完全图灵完备的配置语言，更倾向于总函数语言或原始递归语言，甚至可以在求值步骤上设置“gas”限制。
- 也有人指出，即使是非图灵完备的系统也可能卡住或变得复杂；真正的问题是简单性、终止保证，以及对求值进行界定。
比较与替代方案
- Jsonnet、Kapitan、CUE、Dhall、Nix、Nickel、Starlark、HCL、Lua、YAML 模板、TypeScript 作为 DSL，甚至 WASM，都被讨论为配置或配置生成选项。
- JSON/YAML 加模板被广泛视为一种糟糕但流行的折中方案，这表明存在尚未被满足的需求。
- Lua 因其小巧、可嵌入、可沙箱化，被称赞为“几乎完美”的配置语言。
语法与易用性
- 围绕逗号和尾随逗号的争论：有人希望逗号可选、以换行作为分隔；另一些人则重视冗余带来的错误检测能力以及行内列表。
- “新语言是 JSON 的超集”这一说法受到质疑，尤其是在一些边缘情况上（例如代理对），这表明显式的 JSON 模式更安全。
配置 vs 基础设施与工作流
- 有人认为真正的问题不是简单的“配置”，而是基础设施描述和工作流编排被迫塞进配置语言里。
- 对 DRY 与冗长的看法也不一致：一些人更喜欢在基础设施配置中直接复制粘贴以求清晰；另一些人则希望用抽象来表达“相同但有变化”，避免逻辑漂移。
配置是一个真实问题
- 尽管大家常常对“又一种配置语言”感到疲惫，但一些评论强调，错误配置是停机和复杂性的一个重要现实来源，因此在这一领域进行实验是有理由的。