Pkl, uma linguagem de programação para configuração

Artigo original ↗ Discussão no Hacker News ↗

A Apple abriu o código do Pkl, uma linguagem de configuração tipada e programável, feita para gerar formatos como YAML e JSON enquanto adiciona templates, validação e ferramentas de IDE. Entusiastas destacam seu sucesso dentro da Apple, especialmente para lidar com configurações complexas de Kubernetes e Terraform, e a veem como uma alternativa mais sustentável a YAML com templates de strings e charts do Helm. Céticos questionam a necessidade de mais uma linguagem de configuração — especialmente uma Turing-completa, baseada em Java/GraalVM e sem bindings para Python/.NET — e debatem se DSLs de configuração mais ricas realmente resolvem mais problemas do que criam.

O que é o Pkl e suas principais funcionalidades

  • Nova linguagem de “configuração como código”: dados declarativos mais construções de uso geral (tipos, condicionais, loops, imports).
  • Gera outros formatos (JSON, YAML, XML, PLIST, etc.) e pode ser incorporada via bindings (atualmente Go, Java, Kotlin, Swift) ou usada via CLI.
  • Tipagem estática forte e validação: restrições como intervalos, regex e templates/schemas mais ricos; podem ser compartilhados por meio de um “Pantry” de templates reutilizáveis.
  • Construída sobre GraalVM/Truffle; implementação única usada pela CLI e pelos bindings da linguagem; planos para incorporação no estilo C/FFI.

Casos de uso relatados

  • Uso intenso dentro da Apple por anos: manifests do Kubernetes, Terraform, alertas, config de infraestrutura, geração para múltiplos destinos (configs de monitoramento + documentação).
  • Vários კომენტadores dizem que ela substituiu o Helm em suas empresas para k8s, evitando template de strings e problemas de indentação em YAML.
  • Proposta para pipelines de configuração com múltiplas saídas (por exemplo, uma fonte Pkl → k8s, Prometheus, documentação, config da aplicação) e como alternativa mais segura a “config em Python/TypeScript”.

Comparações com ferramentas existentes

  • Frequentemente comparada a: YAML/JSON (+ JSON Schema), Helm, Terraform/HCL, Jsonnet, Dhall, CUE, Nix, Starlark, Lua.
  • Comparada a JSON/YAML: adiciona tipos, templates, validação, reutilização; evita template de strings frágil.
  • Em relação ao Jsonnet: configuração programável semelhante, mas o Pkl é tipado e tem forte suporte de IDE; o Jsonnet é elogiado pela simplicidade e pelos bindings já existentes.
  • Em relação ao CUE/Dhall: o Pkl é Turing-completo (mais expressivo, mais risco); CUE/Dhall enfatizam terminação e bases lógicas/tipadas mais principiadas.
  • Em relação a “apenas usar Python/TypeScript”: defensores argumentam que isso traz dores de empacotamento/runtime e código arbitrário inseguro, sem sandbox; críticos dizem que introduzir uma nova DSL é pior do que usar uma linguagem geral familiar.

Ferramentas, ergonomia e preocupações de implementação

  • Suporte a IDE: plugin nativo para IntelliJ, plugins básicos para VS Code/neovim; LSP “em breve”. Alguns questionam por que o LSP não foi a prioridade.
  • Alguns se preocupam com runtime e tamanho do binário (binário nativo baseado em Graal ~100MB), dependência de Java e ausência de bindings para .NET/Python/Node.
  • Outros elogiam a futura biblioteca C e observam que Graal/Truffle permitem forte otimização e incorporação poliglota.

Segurança, complexidade e Turing-completude

  • Acesso embutido a HTTP/sistema de arquivos mais Turing-completude levantam preocupações de segurança e de “config lenta”; os mantenedores apontam flags e opções de sandboxing.
  • Debate sobre se configurações deveriam ser Turing-completas: alguns querem poder total para transformações arbitrárias; outros preferem garantias de terminação e controle de fluxo muito limitado.

Entusiasmo vs. ceticismo

  • Entusiastas: chamam de uma das melhores ferramentas internas da Apple, “encantadora” em comparação com Helm/YAML; gostam de config com segurança de tipos, reutilização, validação na IDE e compartilhamento entre linguagens.
  • Céticos: veem como “mais uma linguagem de configuração”, temem que DSLs de config virem mini-programas ilegíveis, preferem YAML+JSON Schema, Jsonnet, Cue ou simplesmente usar linguagens reais.
  • Alguns desconfiam do histórico de código aberto da Apple e questionam a simpatia da comunidade no longo prazo e o foco multiplataforma.
  • A colisão de nome com o “pickle” do Python e arquivos .pkl é observada como potencialmente confusa.