Pkl, a Programming Language for Configuration

Original Article ↗ Hacker News Discussion ↗

Apple has open-sourced Pkl, a typed, programmable configuration language meant to generate formats like YAML and JSON while adding templates, validation and IDE tooling. Enthusiasts highlight its success inside Apple, especially for taming complex Kubernetes and Terraform setups, and see it as a more maintainable alternative to string-templated YAML and Helm charts. Skeptics question the need for yet another config language—especially one that’s Turing-complete, Java/GraalVM-based and lacking Python/.NET bindings—and debate whether richer config DSLs actually solve more problems than they create.

What Pkl Is and Core Features

  • New “configuration as code” language: declarative data plus general-purpose constructs (types, conditionals, loops, imports).
  • Generates other formats (JSON, YAML, XML, PLIST, etc.) and can be embedded via bindings (currently Go, Java, Kotlin, Swift) or used via CLI.
  • Strong static typing and validation: constraints like ranges, regexes, and richer templates/schemas; can be shared via a “Pantry” of reusable templates.
  • Built on GraalVM/Truffle; single implementation used by CLI and language bindings; plans for a C/FFI-style embedding.

Reported Use Cases

  • Heavy use inside Apple for years: Kubernetes manifests, Terraform, alerts, infra config, multi-target generation (monitoring configs + docs).
  • Several commenters say it replaced Helm in their orgs for k8s, avoiding string templating and YAML indentation issues.
  • Proposed for multi-output config pipelines (e.g., one Pkl source → k8s, Prometheus, docs, app config) and as a safer alternative to “config in Python/TypeScript.”

Comparisons to Existing Tools

  • Often compared to: YAML/JSON (+ JSON Schema), Helm, Terraform/HCL, Jsonnet, Dhall, CUE, Nix, Starlark, Lua.
  • Compared to JSON/YAML: adds types, templating, validation, reuse; avoids fragile string templating.
  • Versus Jsonnet: similar “programmable config,” but Pkl is typed and has strong IDE tooling; Jsonnet praised for simplicity and existing bindings.
  • Versus CUE/Dhall: Pkl is Turing-complete (more expressive, more risk); CUE/Dhall emphasize termination and more principled logic/type foundations.
  • Versus “just use Python/TypeScript”: supporters argue those bring packaging/runtime headaches and unsafe, unsandboxed arbitrary code; critics say introducing a new DSL is worse than using a familiar general language.

Tooling, Ergonomics, and Implementation Concerns

  • IDE support: native IntelliJ plugin, basic VS Code/neovim plugins; LSP “coming soon.” Some question why LSP wasn’t primary.
  • Some worry about runtime and binary size (Graal-based native binary ~100MB), Java dependency, and lack of .NET/Python/Node bindings.
  • Others praise planned C library and note Graal/Truffle enable strong optimization and polyglot embedding.

Safety, Complexity, and Turing-Completeness

  • Built-in HTTP/filesystem access plus Turing-completeness raise security and “slow config” concerns; maintainers point to sandboxing flags and options.
  • Debate over whether configs should be Turing-complete at all: some want full power for arbitrary transforms; others prefer termination guarantees and very limited control flow.

Enthusiasm vs. Skepticism

  • Enthusiasts: call it one of the best internal Apple tools, “delightful” compared to Helm/YAML; like type-safe config, reuse, IDE validation, and cross-language sharing.
  • Skeptics: see “yet another config language,” fear config DSLs become unreadable mini-programs, prefer YAML+JSON Schema, Jsonnet, Cue, or simply using real languages.
  • Some distrust Apple’s open-source track record and question long-term community friendliness and cross-platform focus.
  • Naming collision with Python’s “pickle” and .pkl files is noted as potentially confusing.