Pkl，一种用于配置的编程语言

Pkl 是什么以及核心特性

• 新的“configuration as code”语言：声明式数据加上通用构造（类型、条件、循环、导入）。
• 可生成其他格式（JSON、YAML、XML、PLIST 等），并可通过绑定嵌入使用（目前有 Go、Java、Kotlin、Swift），或通过 CLI 使用。
• 强静态类型和验证：范围、正则等约束，以及更丰富的模板/模式；可通过可复用模板的“Pantry”共享。
• 基于 GraalVM/Truffle；CLI 和语言绑定共用单一实现；计划支持类似 C/FFI 的嵌入方式。

报道中的使用场景

• Apple 内部多年重度使用：Kubernetes manifests、Terraform、告警、基础设施配置、多目标生成（监控配置 + 文档）。
• 多位评论者表示它已在各自组织中取代 Helm 用于 k8s，避免了字符串模板和 YAML 缩进问题。
• 被提议用于多输出配置流水线（例如一个 Pkl 源 → k8s、Prometheus、文档、应用配置），以及作为“在 Python/TypeScript 中写配置”的更安全替代方案。

与现有工具的比较

• 常被拿来比较的对象：YAML/JSON（+ JSON Schema）、Helm、Terraform/HCL、Jsonnet、Dhall、CUE、Nix、Starlark、Lua。
• 与 JSON/YAML 相比：增加类型、模板、验证、复用；避免脆弱的字符串模板。
• 与 Jsonnet 相比：同样是“可编程配置”，但 Pkl 是有类型的，并且有强 IDE 工具支持；Jsonnet 因其简单性和现有绑定而受到称赞。
• 与 CUE/Dhall 相比：Pkl 是图灵完备的（表达力更强，风险也更高）；CUE/Dhall 强调终止性和更有原则的逻辑/类型基础。
• 与“直接用 Python/TypeScript”相比：支持者认为那会带来打包/运行时麻烦，以及不安全、未沙箱化的任意代码；批评者则认为引入一种新的 DSL 比使用熟悉的通用语言更糟。

工具、易用性与实现方面的担忧

• IDE 支持：原生 IntelliJ 插件，基础的 VS Code/neovim 插件；LSP“即将推出”。有人质疑为何没有把 LSP 作为首要方案。
• 一些人担心运行时和二进制体积（基于 Graal 的原生二进制约 100MB）、Java 依赖，以及缺少 .NET/Python/Node 绑定。
• 其他人则称赞计划中的 C 库，并指出 Graal/Truffle 使其具备强优化和多语言嵌入能力。

安全性、复杂性与图灵完备性

• 内置 HTTP/文件系统访问以及图灵完备性带来安全与“配置太慢”的担忧；维护者则指出有沙箱标志和相关选项。
• 关于配置是否应当图灵完备的争论：有些人希望拥有处理任意转换的完整能力；另一些人更偏好可终止性保证和非常有限的控制流。

热情与怀疑

• 热情者：称其为 Apple 内部最好的工具之一，与 Helm/YAML 相比“令人愉悦”；喜欢类型安全配置、复用、IDE 验证和跨语言共享。
• 怀疑者：认为这只是“又一种配置语言”，担心配置 DSL 会变成难读的微型程序，更偏好 YAML+JSON Schema、Jsonnet、Cue，或干脆直接使用真正的编程语言。
• 也有人不信任 Apple 的开源记录，并质疑其长期社区友好度和跨平台聚焦。
• 还提到它的命名与 Python 的“pickle”和 .pkl 文件可能产生混淆。