Pkl, un lenguaje de programación para configuración

Apple ha liberado como open source Pkl, un lenguaje de configuración tipado y programable, pensado para generar formatos como YAML y JSON mientras añade plantillas, validación y herramientas de IDE. Los entusiastas destacan su éxito dentro de Apple, especialmente para domar configuraciones complejas de Kubernetes y Terraform, y lo ven como una alternativa más mantenible al YAML con plantillas de cadenas y a los charts de Helm. Los escépticos cuestionan la necesidad de otro lenguaje de configuración —sobre todo uno Turing-complete, basado en Java/GraalVM y sin bindings para Python/.NET— y debaten si los DSL de configuración más ricos realmente resuelven más problemas de los que crean.

Qué es Pkl y sus funciones principales

  • Nuevo lenguaje de “configuration as code”: datos declarativos más construcciones de propósito general (tipos, condicionales, bucles, imports).
  • Genera otros formatos (JSON, YAML, XML, PLIST, etc.) y puede integrarse mediante bindings (actualmente Go, Java, Kotlin, Swift) o usarse vía CLI.
  • Tipado estático fuerte y validación: restricciones como rangos, expresiones regulares y plantillas/esquemas más ricos; se pueden compartir mediante una “Pantry” de plantillas reutilizables.
  • Basado en GraalVM/Truffle; una sola implementación usada por la CLI y los bindings del lenguaje; hay planes para una integración estilo C/FFI.

Casos de uso reportados

  • Uso intensivo dentro de Apple durante años: manifests de Kubernetes, Terraform, alertas, configuración de infraestructura, generación para múltiples destinos (configuraciones de monitoreo + documentación).
  • Varios comentaristas dicen que sustituyó Helm en sus organizaciones para k8s, evitando el templating de cadenas y los problemas de indentación de YAML.
  • Propuesto para pipelines de configuración de salida múltiple (por ejemplo, una sola fuente Pkl → k8s, Prometheus, documentación, configuración de aplicaciones) y como una alternativa más segura a “config en Python/TypeScript”.

Comparaciones con herramientas existentes

  • Frecuentemente comparado con: YAML/JSON (+ JSON Schema), Helm, Terraform/HCL, Jsonnet, Dhall, CUE, Nix, Starlark, Lua.
  • Comparado con JSON/YAML: añade tipos, templating, validación y reutilización; evita el frágil templating de cadenas.
  • Frente a Jsonnet: similar “configuración programable”, pero Pkl está tipado y tiene fuerte tooling para IDE; Jsonnet es valorado por su simplicidad y bindings existentes.
  • Frente a CUE/Dhall: Pkl es Turing-complete (más expresivo, más riesgo); CUE/Dhall enfatizan la terminación y fundamentos lógicos/de tipos más principistas.
  • Frente a “usar Python/TypeScript”: los partidarios argumentan que eso trae problemas de empaquetado/runtime y código arbitrario inseguro y sin sandbox; los críticos dicen que introducir un nuevo DSL es peor que usar un lenguaje general conocido.

Herramientas, ergonomía y preocupaciones de implementación

  • Soporte de IDE: plugin nativo de IntelliJ, plugins básicos de VS Code/neovim; LSP “próximamente”. Algunos cuestionan por qué LSP no fue la primera prioridad.
  • A algunos les preocupa el runtime y el tamaño del binario (binario nativo basado en Graal ~100MB), la dependencia de Java y la ausencia de bindings para .NET/Python/Node.
  • Otros elogian la biblioteca C planificada y señalan que Graal/Truffle permiten una fuerte optimización e integración poliglota.

Seguridad, complejidad y Turing-completitud

  • El acceso integrado a HTTP/sistema de archivos más la Turing-completitud plantean preocupaciones de seguridad y de “configuración lenta”; los mantenedores apuntan a flags de sandboxing y opciones.
  • Debate sobre si las configuraciones deberían ser Turing-complete o no: algunos quieren poder total para transformaciones arbitrarias; otros prefieren garantías de terminación y un control de flujo muy limitado.

Entusiasmo frente a escepticismo

  • Entusiastas: lo llaman una de las mejores herramientas internas de Apple, “delightful” comparado con Helm/YAML; les gusta la configuración con seguridad de tipos, la reutilización, la validación en IDE y el uso compartido entre lenguajes.
  • Escépticos: lo ven como “otro lenguaje de configuración más”, temen que los DSL de configuración se conviertan en mini-programas ilegibles, prefieren YAML+JSON Schema, Jsonnet, Cue, o simplemente usar lenguajes reales.
  • Algunos desconfían del historial de open source de Apple y cuestionan la amabilidad a largo plazo con la comunidad y el enfoque multiplataforma.
  • Se señala el choque de nombre con el “pickle” de Python y los archivos .pkl como algo potencialmente confuso.