A reasonable configuration language
Configuration files are increasingly evolving from simple data formats like JSON or YAML into full-fledged, sometimes Turing-complete, languages, raising questions about where to draw the line between “config” and “code.” Commenters weigh the trade-offs between specialized configuration languages (such as HCL, Dhall, Jsonnet, Nix, Lua-based approaches, or the newly proposed RCL) and reusing general-purpose languages, focusing on safety, readability, tooling, and cross-language interoperability. Many argue for constrained, side-effect‑free, declarative languages that can still express reuse and logic, while others see the proliferation of bespoke solutions as evidence that configuration for complex systems remains an unsolved—and operationally critical—problem.
Escalating complexity of configuration
- Many systems start with simple formats (INI/JSON/YAML) then gradually add overlays, templating, expressions, and eventually full computation.
- This “rabbit hole” is seen as almost inevitable for provisioning and infrastructure tools; each ecosystem reinvents similar workflow/config engines.
- Some argue most software actually stops at hierarchical parameters; only infra/workflow systems fall deep into config complexity.
Why a special configuration language at all?
- Skeptics ask why not just use existing programming languages plus data formats.
- Proponents reply that config has distinct needs: restricted power, easier learning curve, language-agnostic interoperability, and safer processing (e.g., static analysis of configs without executing arbitrary code).
- There’s also a social angle: many infra users don’t want to become full-blown programmers, yet still need some abstraction and reuse.
Turing-completeness, safety, and evaluation
- Several comments push back on fully Turing-complete config, preferring total or primitive-recursive languages, possibly with “gas” limits on evaluation steps.
- Others note that even non-Turing-complete systems can hang or be complex; the real issues are simplicity, termination guarantees, and bounding evaluation.
Comparisons and alternatives
- Jsonnet, Kapitan, CUE, Dhall, Nix, Nickel, Starlark, HCL, Lua, YAML templating, TypeScript-as-DSL, and even WASM are discussed as configuration or config-generating options.
- JSON/YAML-plus-templating is widely seen as a bad but popular compromise, indicating unmet needs.
- Lua receives praise as a tiny, embeddable, sandboxable “almost perfect” config language.
Syntax and ergonomics
- Debates over commas and trailing commas: some want them optional with line breaks as separators; others value redundancy for error detection and inline lists.
- Claims that new languages are “supersets of JSON” are challenged on edge cases (e.g., surrogate pairs), suggesting explicit JSON modes are safer.
Configuration vs infrastructure and workflows
- Some argue the real problem isn’t simple “config” but infrastructure description and workflow orchestration being forced into config languages.
- Views diverge on DRY vs verbosity: some prefer copy-paste in infra configs for clarity; others want abstractions to express “same with variation” and avoid logical drift.
Configuration as a real problem
- Despite fatigue about “yet another config language,” several comments stress that misconfiguration is a major practical source of downtime and complexity, so experimentation in this space is seen as justified.