Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Prologue — One SRE Sighing at a Thousand-Line YAML

Spring 2026, a platform-team meeting room.

SRE: "This Helm values.yaml is 1,400 lines. One bad indent broke prod yesterday."

PM: "Why is it so long?"

SRE: "3 envs times 47 microservices times 4 regions. That's 564 combinations, and they differ by maybe 5 percent. But YAML has no abstraction, so we copy-paste everything."

PM: "Can't you use something else?"

SRE: "Like what? Jsonnet? Helm templates? Kustomize? CUE? Pkl? HCL for Terraform? Starlark for Bazel? TypeScript via Pulumi? Nix? We use all six in the company already. No one ever decided which one to recommend."

That is 2026. We live in an **age of configuration explosion**. Kubernetes YAML, Terraform HCL, Helm values, Backstage catalog, ArgoCD ApplicationSet, GitHub Actions, CircleCI orbs, Buildkite pipeline, Dockerfile, Bazel BUILD, devcontainer.json, dprint config, biome.json, package.json, pyproject.toml — every microservice has at least thirty config files. JSON/YAML/TOML were not enough, so new languages appeared, and in 2026 **CUE, Pkl, and KCL form the big three**. Around them, Jsonnet, HCL, Nix, Starlark, and Dhall hold their niches, while the Pulumi camp shouts: "Just use TypeScript."

This post maps the 2026 configuration-language landscape — where each language came from, what problem it solves, where it fails, and what your team should actually pick.

Chapter 1 · The 2026 Configuration Language Landscape — Four Categories

A bird's-eye-view table first.

| Category | Representative languages | Core idea |

| --- | --- | --- |

| Data + constraints | CUE, Pkl, KCL | Value and schema in the same language. Type equals partial data |

| Functional / lambda | Dhall, Jsonnet | Pure functions, compute data |

| Domain-specific (IaC) | HCL, Nix | Single domain (Terraform / NixOS) |

| Build determinism | Starlark | Python sandbox for Bazel |

| General language as config | Pulumi (TS / Py / Go), CDK | Use a normal programming language for IaC |

| Task runner | Mage, Earthfile, Just, Taskfile | Make alternatives, task definitions |

| Classic data | JSON, YAML, TOML | Pure serialization, no abstraction |

The key is that each category solves a different problem. CUE addresses "what to do when YAML grows to 100 files — how to validate and compose," Pulumi addresses "why can't IaC engineers have IDE autocomplete and unit tests," and Starlark addresses "why does my build produce a different artifact every time (non-determinism)." No single language solves all of them.

Another axis: **Turing completeness**. Jsonnet, Dhall, and CUE are intentionally non-Turing-complete (or weakly so). You cannot write an infinite loop, so evaluation always terminates. Pulumi (TS), Starlark, and Pkl are richer but can loop forever. This trade-off sits at the heart of the eternal "how much logic belongs in config" debate.

Chapter 2 · "Why JSON/YAML Are Not Enough" — A Motivation Analysis

In 2026 the "just use YAML" camp is still loud. Their argument:

> "YAML is readable by every language. No extra toolchain. Humans can read it. Good enough."

Fair. Small projects end with YAML. But once any of the following five symptoms appear, YAML hits a wall.

**Symptom 1 · Duplication**. Per-environment values-dev.yaml / values-stg.yaml / values-prod.yaml repeat 95 percent of the same keys. Fix one place, you have to fix three. Human error explodes.

**Symptom 2 · No validation**. `replicas: "3"` (a string) sneaks through until k8s rejects it. JSON Schema and OpenAPI can validate externally, but the IDE does not catch it instantly.

**Symptom 3 · Composition**. You need to merge base plus overlay. Helm uses Go templates, Kustomize uses strategic merge patches, Jsonnet uses object composition. YAML alone cannot do it.

**Symptom 4 · Variables**. "Reference this value in five places" is impossible. YAML anchors and aliases only work within a single file.

**Symptom 5 · Conditionals and loops**. "If prod then replicas equals 5 else 1" is not expressible. So people layer a text-substitution engine (Helm Go templates, Jinja) on top. Now you are **generating indentation-sensitive YAML with a text engine that knows nothing about indentation**. This is 90 percent of Helm chart debugging.

These five reasons are why "configuration languages" exist. Abstraction, validation, composition, variables, logic — solved **at the language level**. In 2026 CUE, Pkl, and KCL compete for that seat.

Chapter 3 · CUE — Marcel van Lohuizen's Data + Constraints Unification

CUE (Configure, Unify, Execute) was built by Marcel van Lohuizen, a former Google engineer. He was a core contributor to Go and one of the designers of Protocol Buffers. What he saw at Google was the question of **how to validate and compose configuration files when they grow into hundreds of millions of lines**. CUE is his answer.

CUE's central insight: **types and values are the same**. `int` is "the set of all integers." `42` is "the set containing only 42." Both are the same kind of object — a constraint. The operation that combines two constraints is called **unification**.

// Schema

#Server: {

port: int & >0 & <65536

replicas: int | *3 // default 3

env: "dev" | "stg" | "prod"

}

// Value

server: #Server & {

port: 8080

env: "prod"

}

// replicas not specified, so the default 3 is used

Here `int & >0 & <65536` means "an integer greater than 0 and less than 65536." If you put `port: 70000` into `server`, unification fails and CUE raises an error. That elegance — **schema and data in the same language** — is CUE's draw.

Another core property: **commutativity**. `A & B = B & A`. Order does not matter. So those nasty "values precedence" rules from Helm vanish.

CUE ecosystem in 2026:

- **Cuelang official tooling**: `cue eval`, `cue export`, `cue vet`, `cue mod`

- **Holos**: CUE-based GitOps for k8s

- **Dagger CI/CD**: started with CUE, moved to Go SDK in 2024

- **kpt with CUE**: Google Cloud's k8s configuration tool

- **Istio**: uses CUE in parts of its internal configuration validation

CUE's weakness: **a steep learning curve**. Unification, disjunction, definitions, hidden fields, optional, default — there are many concepts. Selling "why not just use YAML" takes six months. And **error messages are hard**. When unification fails, locating the clashing site is painful.

Chapter 4 · Pkl (Apple, Feb 2024) — Apple's Open Source Configuration Language

In February 2024 Apple suddenly open-sourced a configuration language called Pkl (pickle, pkl.dev). That was a shock. Apple is famously stingy with OSS, yet here was an announcement: "we have used this internally for years, and we're giving it to you."

Pkl's design philosophy:

- **Object oriented**: classes, modules, inheritance. Heavy Scala influence (one of the designers comes from the Scala world).

- **Rich type system**: Listable, Mapping, Listing, Class, constraints, null safety

- **Multiple output formats**: pcf (native), JSON, YAML, plist, .properties, XML

- **Strong IDE integration**: official IntelliJ and VS Code plugins, LSP support, live validation

class Server {

port: Int(this > 0 && this < 65536)

replicas: Int = 3

env: "dev" | "stg" | "prod"

}

api = new Server {

name = "api"

port = 8080

env = "prod"

}

The syntax feels more familiar than CUE. A Java, Kotlin, or Scala engineer reads it in five minutes. And **the error messages are excellent**. The tool points to the exact place a constraint failed. You can see years of Apple internal polish.

Pkl's killer feature: **language bindings**. Java, Kotlin, Swift, Go, and Python have SDKs that load a Pkl file directly as a typed object. It works like Spring Boot loading application.properties / application.yml, but Pkl gives you application.pkl with full type safety. This is the answer to "why did Apple build this": type-safe configuration for Swift / Java / Kotlin backends.

Pkl adoption in 2026:

- Apple internal: extensive (publicly hinted, not detailed)

- AWS, Booking.com, ING reportedly evaluating

- In Korea, Toss did a PoC on Pkl for some backend config (announced at SLASH 2025)

- In Japan, Sansan and parts of Mercari use Pkl for Java/Kotlin backend config

Weakness: **a relatively new language**. Released in 2024, the ecosystem is still small. And being Apple-led, the project follows Apple's pace and governance. Kubernetes-centric domains are weak — Pkl can emit YAML/JSON, but k8s toolchain integration lags.

Chapter 5 · KCL (Kusion Stack, CNCF Sandbox 2024)

KCL (Kusion Configuration Language) began at Ant Group in China and was open-sourced as part of the Kusion Stack project in 2023, then admitted to the CNCF Sandbox in 2024. As of 2026 it is preparing the move to Incubation.

KCL's design:

- **Python-like syntax**: indentation, colons, familiar

- **Static typing**: strong type checking

- **OOP**: classes, inheritance, mixins

- **k8s-first**: KRM (Kubernetes Resource Model) friendly

schema Server:

port: int

replicas: int = 3

env: "dev" | "stg" | "prod"

check:

port > 0 and port < 65536, "port out of range"

api = Server {

name = "api"

port = 8080

env = "prod"

}

KCL is the easiest to read. A Python engineer writes it in five minutes. **Error messages are clear**, **the compiler is fast** (Rust plus LLVM), and KCL **focuses on Kubernetes** — kcl-operator, kclvm-go, KCL-as-Crossplane-composition, KCL-as-Argo-CD-plugin, and so on. K8s ecosystem integration is the most active here.

KCL's place in 2026:

- **CNCF Sandbox** (entered 2024), preparing Incubation

- **Ant Group, Alibaba** internal heavy use

- Dedicated **KCL track at KubeCon China 2025**

- Some Korean megacorps (a telco) running internal PoCs as standard

- Japan adoption still limited

Weakness: **less strong outside k8s**. For general backend config, Pkl wins; for pure data + constraints, CUE is more elegant. And **being China-led is a political variable** for a few Western enterprises, slowing adoption (KCL is fully OSS under CNCF governance, but perception matters).

Chapter 6 · Dhall — Functional, Old, and Solid

Dhall (dhall-lang.org) was created in 2017 by Gabriel Gonzalez, a heavyweight of the Haskell community. As of 2026 it is the oldest of the "modern configuration languages."

Dhall's design philosophy:

- **Total**: every evaluation terminates. Infinite loops are impossible

- **Pure functional**: deep Haskell influence

- **Partial dependent typing**: function signatures can constrain values

- **First-class imports**: import from URL or file, verified by hash

let Env = < Dev | Stg | Prod >

let Server =

{ name : Text

, port : Natural

, replicas : Natural

, env : Env

}

let api : Server =

{ name = "api"

, port = 8080

, replicas = 3

, env = Env.Prod

}

in api

Dhall is **the language of trust**. URL imports verify content hashes, so even if someone alters the upstream, you detect it instantly. Import caches are hash-keyed too. This is getting renewed attention in the supply-chain-security era.

Another asset: **converters**. Dhall has `dhall-to-yaml`, `dhall-to-json`, `dhall-to-bash`, `dhall-to-nix`, and more. "Write once in Dhall, emit many outputs" is a real pattern.

Dhall's position in 2026: **few users, but devoted**. Mostly used in the Haskell and PureScript communities, and by a handful of security-conscious GitOps teams. New adoption has plateaued, but **maintenance is steady**. Korea and Japan adoption is near-zero (a few functional-programming holdouts).

Weakness: **a very steep learning curve**. Functional concepts (no monads, but folds and recursion) trip up newcomers. And **the ecosystem is small** — IDE support is weaker than CUE, Pkl, and KCL.

Chapter 7 · Jsonnet — Google's Data Template plus Sjsonnet, Tanka, Grafonnet

Jsonnet (jsonnet.org) was open-sourced by Google in 2014 as a simplification of BCL (Borg Configuration Language). In 2026 it remains **the most widely used "abstraction over JSON"** language.

Jsonnet's design:

- **Extension of JSON**: every JSON document is valid Jsonnet

- **Functions, objects, inheritance, patches**: powerful object composition

- **Turing complete**: functional plus object-oriented, supports recursion

- **Pure**: no side effects, same input gives same output

local Server(env) = {

port: 8080,

replicas: if env == "prod" then 5 else 1,

env: env,

};

{

dev: Server("dev"),

prod: Server("prod"),

}

Three reasons Jsonnet's ecosystem is still strong in 2026:

**1. Tanka (Grafana Labs)**: a Jsonnet-based tool for managing k8s. Grafana Labs publicly runs its entire infrastructure on Tanka. It is the most serious Helm alternative.

**2. Grafonnet**: a Jsonnet library for defining Grafana dashboards as code. A standard tool for teams with dozens of dashboards.

**3. Sjsonnet (Databricks)**: a Scala-based Jsonnet interpreter. It is 5 to 50 times faster than the official C++ interpreter, drastically cutting build time on huge Jsonnet codebases.

Also: **Bazel plus Jsonnet** is a popular combo. Bazel build definitions in Starlark, generated configs (k8s manifests and the like) in Jsonnet.

Jsonnet use cases in 2026:

- **Grafana Labs**: company-wide infrastructure (millions of lines of Jsonnet)

- **Databricks**: cluster configuration (they built Sjsonnet)

- **Red Hat**: parts of OpenShift configuration

- **Kakao**: some infrastructure teams running k8s GitOps in Jsonnet

- **Mercari**: parts of the ad platform reportedly use Jsonnet

Weakness: **no type system**. Unlike CUE / Pkl / KCL, Jsonnet is dynamically typed. Refactoring at scale is painful. And **error messages often arrive as deep stack traces**, making it hard to find the actual problem.

Chapter 8 · HCL (HashiCorp) — Terraform's Language

HCL (HashiCorp Configuration Language) was created by HashiCorp in 2014. In 2026 it is **the most widely used IaC language in the world** (Terraform dominates). We are talking about HCL2 here.

variable "env" {

type = string

}

resource "kubernetes_deployment" "api" {

metadata {

name = "api"

}

spec {

replicas = var.env == "prod" ? 5 : 1

template {

spec {

container {

name = "api"

image = "myapi:latest"

}

HCL's design:

- **Declarative**: a resource is the desired state

- **Expressions**: `for`, conditional, function calls

- **Modules**: reusable units

- **JSON-compatible**: every HCL document is expressible in JSON (humans prefer HCL form)

After HashiCorp's acquisition by IBM and the license change to BSL in 2024, **OpenTofu** (Linux Foundation, forked in 2023) grew fast and by 2026 is the de facto OSS replacement. Both still use HCL, but OpenTofu adopts new features faster (provider-defined functions, state encryption, and so on).

HCL's strength: **the Terraform ecosystem itself**. Every cloud has provider definitions in HCL, every module registry is HCL. Using Terraform almost forces you into HCL.

Weakness: **weak outside Terraform**. Nomad, Vault, and Packer use HCL too, but other domains rarely touch it. And HCL is intentionally non-Turing-complete, which makes complex logic hard — hence CDK for Terraform (CDKTF).

Chapter 9 · Nix Lang plus NixOS — The Essence of Declarative Systems

Nix dates back to 2003 and Eelco Dolstra's PhD thesis. As of 2026 Nix Lang has **the most fanatical user base of any configuration language**. NixOS, nixpkgs, and Nix Flakes are all written in Nix Lang.

{ config, pkgs, ... }:

{

services.nginx = {

enable = true;

virtualHosts."example.com" = {

forceSSL = true;

enableACME = true;

locations."/" = {

root = "/var/www";

};

environment.systemPackages = with pkgs; [

vim

git

htop

];

}

Nix Lang's design:

- **Pure functional, lazy evaluation**: only evaluate what is needed

- **Reproducibility**: same input gives same output, bit for bit

- **Immutable store**: every build result lives in /nix/store under a hash directory

- **Nix Flakes**: input pinning, modularization

Nix's allure is **the entire system as code**. NixOS defines the whole OS in Nix configuration. nix-darwin does the same for macOS. home-manager handles user dotfiles the same way.

Nix's position in 2026:

- **Determinate Systems** (co-founded by Eelco): enterprise Nix services

- **NumTide, Tweag**, and other Nix consultancies are stable

- **Jane Street and Anduril** use it as an internal standard

- **Kakao infra teams** publicly experimented with NixOS in 2025

- Japan has functional-community early adopters (a few Mercari engineers)

Nix Lang's infamy: **a brutal learning curve**. The joke goes "Nix is 90 percent hard and 10 percent magic." Error messages are unhelpful, documentation is scattered, magical functions abound. But disciples insist that once you crack it, **every other system feels awkward**.

Chapter 10 · Starlark — Bazel's Deterministic Python

Starlark (formerly Skylark) is a deterministic subset of Python that Google built for Bazel. Its specification was split off and open-sourced in 2020. It is **the configuration language for build systems like Bazel, Buck2 (Meta), Tilt, and Pants**.

def deploy_target(name, env, replicas = 3):

return struct(

name = name,

env = env,

replicas = 5 if env == "prod" else replicas,

)

api_prod = deploy_target("api", "prod")

api_dev = deploy_target("api", "dev")

Starlark's design decisions:

- **Python subset**: same syntax, different semantics

- **Infinite loops possible but sandboxed**: `while True` is legal, but time and memory are bounded

- **No side effects**: no file I/O, no network, no clock access

- **Freezable objects**: guarantees a deterministic build graph

- **Recursion limits**: bounded depth blocks infinite recursion

The philosophy: **builds must be deterministic**. Same inputs (source plus dependencies) yield the same outputs. Only then is caching meaningful, distributed builds possible, and security audits feasible. Plain Python lets you call external APIs at import time, read the clock, or peek at environment variables — and results drift. Starlark forbids that.

Starlark's position in 2026:

- **Bazel** (Google, ubiquitous): Pinterest, Stripe, Two Sigma, Adobe, and more

- **Buck2** (Meta, rewritten in Rust, open-sourced in 2023)

- **Tilt** (k8s local development)

- **Pants** (Python and Java monorepos)

- Korea: Toss reportedly introduced Bazel (Starlark) into a monorepo

- Japan: Mercari and LINE use Bazel broadly

Weakness: **rarely used outside the build domain**. "It looks like Python, why is it separate?" raises an entry barrier. And Bazel itself is heavyweight (BUILD files, WORKSPACE, MODULE.bazel).

Chapter 11 · TypeScript-as-Config (Pulumi) — Configuration in a General-Purpose Language

Pulumi (founded 2018) takes the most provocative stance — **"You do not need a configuration language. Just use TypeScript, Python, Go, or Java."** Pulumi lets you author IaC in a real programming language.

const env = process.env.ENV || "dev";

const replicas = env === "prod" ? 5 : 1;

const deployment = new k8s.apps.v1.Deployment("api", {

spec: {

replicas: replicas,

selector: { matchLabels: { app: "api" } },

metadata: { labels: { app: "api" } },

spec: {

containers: [{

image: "myapi:latest",

}],

});

Pulumi's argument:

- **IDE autocomplete for free**: use the whole TS tool ecosystem

- **Unit-testable**: test IaC code with Jest

- **Unlimited abstraction**: it is a real programming language — libraries, modules, inheritance, all available

- **Type-safe**: providers expose auto-generated TS types

Adjacent camps:

- **AWS CDK** (TypeScript, Python, Java, Go): CloudFormation as code

- **CDKTF**: Terraform as a general language

- **CDK8s**: Kubernetes as a general language

- **SST**: full-stack TS on AWS

Pulumi adoption in 2026:

- **Snowflake, BMW, Mercedes**: enterprise standards

- **Sapphire Ventures Series C, USD 41M in 2023**

- In Korea, Toss and Daangn have reported partial adoption

- Japan sees Mercari and SmartHR using Pulumi or CDK

The pushback: **general languages are too powerful**. Infinite loops, side effects, non-determinism are all possible. "Same code I planned yesterday produced a different plan today" stories exist. So Pulumi keeps adding **purity guardrails** (state locking, preview vs apply).

Chapter 12 · Task Runners — Mage, Earthfile, Just, Taskfile

Right next to configuration languages sit **task-runner languages**. Four contenders for Make's throne.

**Mage (Go)**: define build tasks in Go. Functions in magefile.go are tasks.

//go:build mage

package main

func Build() error {

return sh.Run("go", "build", "./...")

}

func Test() error {

return sh.Run("go", "test", "./...")

}

Friendly to Go developers, type safe. Overkill for non-Go projects.

**Earthfile (Earthly)**: Dockerfile meets Makefile. Define build steps inside containers.

VERSION 0.7

FROM golang:1.21

WORKDIR /app

build:

COPY . .

RUN go build -o myapp .

SAVE ARTIFACT myapp /myapp

docker:

FROM alpine

COPY +build/myapp /myapp

ENTRYPOINT ["/myapp"]

SAVE IMAGE myapp:latest

Strength: **reproducibility**. Every build runs in a clean container, so "works on my machine" disappears. Cost: **container build overhead** every time.

**Just (justfile)**: a simplified Make. Closer to command aliases than full dependency graphs.

default:

just --list

build:

cargo build --release

test:

cargo test

deploy ENV="dev":

./scripts/deploy.sh {{ENV}}

Just is written in Rust — fast, clean syntax, cross-shell. Popular for small projects, spreading fast among Korean and Japanese developers.

**Taskfile (Task)**: a YAML-based task runner. Written in Go.

version: '3'

tasks:

build:

cmds:

- go build -o myapp .

test:

cmds:

- go test ./...

deploy:

deps: [build, test]

cmds:

- ./scripts/deploy.sh

Low cognitive cost (it is YAML). Supports dependencies, variables, and watch mode. Sits between Make and Just.

Task-runner adoption in 2026 splits along **language affinity**. Go teams pick Mage or Taskfile, Rust teams pick Just, container-first teams pick Earthfile, traditionalists stay on Make.

Chapter 13 · "Just Use TOML / JSON / YAML" — The Opposing View

Across from the configuration-language camp stands a stubborn conservative wing. Their logic is simple.

**1. Every new language is debt**. The team must learn it, tooling is sparse, and migration is hell when maintainers leave. **YAML / JSON / TOML are eternal**.

**2. Configuration should be simple**. Logic inside config means it is code. Code belongs in the codebase. A config file full of if/else/for is a sign of bad abstraction.

**3. Tools should be orthogonal**: validation via JSON Schema, composition via Kustomize / Helm, variables via environment variables — solve each problem with a small tool. A language that tries to solve everything bloats.

**4. Learning cost beats savings**: 100 engineers learning CUE at two weeks each equals 200 weeks, or four engineer-quarters. How many features could ship in that time?

This logic is **correct for small teams and simple domains**. So in 2026, 80 percent of new microservices still start with plain YAML. Configuration languages enter when a team hits the wall.

Interesting compromises:

- **YAML plus JSON Schema plus strong IDE validation**: no abstraction, but instant IDE checks. The VS Code YAML/JSON extensions in 2026 are very good.

- **YAML plus Kustomize**: composition handled by tooling. Still strong in the k8s world.

- **YAML plus cue vet**: use CUE just for validation while keeping data in YAML. A great gateway to CUE.

Chapter 14 · Korea and Japan — Toss, Kakao, and Mercari in Practice

A summary of Korean and Japanese enterprise adoption (based on public conference talks and blogs).

**Toss**: operates over 1,000 backend microservices. Default config is application.yml (Spring Boot convention) plus Spring Cloud Config Server. Some payment and banking backends are doing a **Pkl PoC** (announced at SLASH 2025). Infrastructure is Terraform (HCL) with some Pulumi (TS). A monorepo has Bazel (Starlark) in pilot.

**Kakao**: multi-cloud. **Jsonnet plus Tanka for some infrastructure GitOps** (announced at if(kakao) 2025). **NixOS experiments** by parts of the infra team are public. Standard combo is Terraform (HCL) plus ArgoCD ApplicationSet (YAML).

**Naver**: company standard is YAML plus Helm plus Kustomize. Parts of the ClovaX AI infra adopted Pulumi. Tools like nGrinder still use properties plus YAML.

**LINE**: a global messenger. Bazel (Starlark) is broadly used. Some teams adopted Jsonnet. Main IaC is Terraform (HCL).

**Mercari**: over 200 microservices. Ads and search reportedly use Jsonnet. Some Java and Kotlin backends are **evaluating Pkl**. Standard remains Terraform (HCL) plus Helm (YAML).

**Sansan, SmartHR, Cybozu** and other Japanese SaaS firms: a conservative blend of YAML, Helm, and Terraform; a few experimenting with Pulumi or CDK.

The common pattern: **hybrid**. No single language conquers everything. IaC in HCL, builds in Starlark or Make, k8s in YAML plus Kustomize / Helm, backend config in YAML or Pkl. Bigger teams have multiple standards.

Chapter 15 · Who Should Pick What — A Decision Guide

Finally, a practical guide for what your team should pick.

**Case 1 · K8s YAML over a thousand lines, five environments**

- Quickest path: **Kustomize**. Keep YAML, add a tool. One day to learn.

- Next step: **Helm**. Adds templates. One week to learn.

- More serious: **CUE** or **KCL**. Unified data plus validation. One month to learn.

- Decision criterion: if environments stay simple (three or fewer), Kustomize; if combinations explode (ten plus region or env combos), CUE or KCL.

**Case 2 · Multi-cloud IaC, team fluent in TypeScript**

- Pick: **Pulumi (TypeScript)** or **CDK**. Autocomplete, unit tests, modularity.

- Alternative: Terraform (HCL) plus CDKTF — HCL underneath, TS on top.

- Avoid: forcing HCL on a team that does not know it.

**Case 3 · Monorepo, 100 packages**

- Pick: **Bazel plus Starlark** or **Buck2 plus Starlark**. Deterministic builds, caching.

- Alternative: **Pants** (Python centric), **Nx** (JS/TS centric).

- Avoid: hand-managing the dependency graph in Make.

**Case 4 · Spring Boot backend, application.yml too long**

- Pick: **Pkl**. Strong Java and Kotlin SDKs, type safe.

- Alternative: stick with YAML plus Spring Cloud Config and env-specific profiles.

- Learning cost: about one week.

**Case 5 · NixOS maniac, full-system reproducibility**

- Pick: **Nix Lang**. No real alternative.

- Warning: one to six months of learning. Team buy-in is mandatory.

**Case 6 · Plain GitHub Actions or Docker Compose**

- Pick: **stay on YAML**. The ROI of a config language is not there.

- Booster: add JSON Schema validation, catch issues in the IDE.

**Case 7 · Simple CLI tool config**

- Pick: **TOML**. The de facto standard in Rust-land. Human-friendly.

- Alternatives: JSON (JS-friendly), YAML (Python-friendly).

**Case 8 · Dozens of Grafana dashboards**

- Pick: **Grafonnet (Jsonnet)**. Dashboards as code.

- Alternative: Terraform Grafana provider.

**Principle**: start small. Do not try to conquer everything with one language. **Hybrid is normal**.

Chapter 16 · References

Core specs and documentation:

- CUE official site — https://cuelang.org

- Pkl official site (Apple) — https://pkl-lang.org

- KCL official site (Kusion Stack) — https://kcl-lang.io

- Dhall official site — https://dhall-lang.org

- Jsonnet official site — https://jsonnet.org

- HashiCorp HCL — https://github.com/hashicorp/hcl

- Nix official — https://nixos.org

- Starlark specification — https://github.com/bazelbuild/starlark

- Pulumi — https://www.pulumi.com

Task runners:

- Mage — https://magefile.org

- Earthly Earthfile — https://earthly.dev

- Just — https://just.systems

- Task (Taskfile) — https://taskfile.dev

Ecosystem and tools:

- Tanka (Grafana Labs) — https://tanka.dev

- Grafonnet — https://github.com/grafana/grafonnet

- Sjsonnet (Databricks) — https://github.com/databricks/sjsonnet

- OpenTofu — https://opentofu.org

- Determinate Systems (Nix) — https://determinate.systems

- Buck2 (Meta) — https://buck2.build

- CDK for Terraform — https://developer.hashicorp.com/terraform/cdktf

- AWS CDK — https://aws.amazon.com/cdk/

CNCF and standards:

- KCL CNCF Sandbox — https://www.cncf.io/projects/kcl

- Crossplane Composition with KCL — https://docs.crossplane.io

- Argo CD KCL Plugin — https://github.com/argoproj/argo-cd

Korean and Japanese conferences:

- SLASH 2025 (Toss) — https://toss.tech/slash25

- if(kakao) 2025 — https://if.kakao.com

- KubeCon China 2025 (KCL track) — https://www.cncf.io

- Mercari Engineering Blog — https://engineering.mercari.com

Background and interviews:

- Marcel van Lohuizen on CUE — https://cuelang.org/docs/introduction

- Apple Pkl announcement (Feb 2024) — https://pkl-lang.org/blog

- KCL CNCF Sandbox announcement — https://www.cncf.io/blog/kcl

- Eelco Dolstra (Nix founder) interviews — search engines

Debate and critique:

- "Just use YAML" camp — search https://hn.algolia.com

- Various configuration-language comparison posts

- Pulumi versus Terraform debates — https://www.pulumi.com/blog

This article reflects the state of things as of May 2026, and the configuration-language ecosystem evolves quickly. Pkl (Apple) and KCL (CNCF) adoption shifts every quarter. Verify the latest state before adopting.