Pkl 是苹果推出的旨在取代 JSON 和 YAML 的配置语言。
Pkl（发音为 “Pickle”）是苹果公司在 “配置即代码” 领域的一项创新尝试。它介于传统格式（如 JSON）和全功能编程语言（如 Python）之间，致力于让配置变得更加可靠和易于维护。
Pkl 之所以吸引我，是因为它并不试图成为一种通用的编程语言，而是聚焦于解决一个核心问题：让配置不再麻烦。
作为一个曾多次与 YAML 缩进问题和 JSON 缺少注释功能作斗争的人，我非常期待苹果通过 Pkl 提供的改进。
Pkl 的独特之处配置文件通常从简单的初始状态开始，但随着需求变化逐渐变得复杂。以一个典型的部署配置为例：起初可能只包含几个环境变量，但最终会发展为跨越多个服务的数百行代码。YAML 和 JSON 在处理这种复杂性时表现乏力，而通用编程语言则可能显得大材小用。
Pkl 并非仅仅是另一种配置格式。它将静态配置格式（如 JSON 和 YAML）的特点与编程语言的能力相结合。可以将其视为具有 YAML 简洁性的同时，在需要时能够提供更多功能支持。
// Basic configname = "My Service"port = 8080// Template for shared settingsbaseService { image = "nginx:1.19" healthCheck = true}// Reuse template for specific serviceswebService = new baseService { port = 80}apiService = new baseService { port = 3000}上面的代码展示了 Pkl 的混合特性。它像 YAML 一样简洁易读，但同时支持类似编程语言的抽象和重用功能。
Pkl 强制实施不可变性 —— 一旦定义某个值，就无法修改。这一特性有效避免了因值被意外更改而导致的一系列配置错误。Pkl 还通过模式提供内置验证功能：
class DatabaseConfig { host: String port: Int function validate() { port > 0 && port < 65536 }}模式会在评估配置时对其进行验证，从而在问题进入生产环境前及时发现。
Pkl 的设计旨在无缝融入现有工作流。它支持输出到 JSON、YAML、XML 和 Java Properties 文件。这意味着，你可以使用 Pkl 为需要这些格式的工具生成配置。Pkl 还为多种编程语言提供了集成库：
JVM（Java 和 Kotlin）SwiftGo这些库使得应用程序可以直接读取和解析 Pkl 配置，无需借助中间格式的 JSON 或 YAML 文件。
考虑典型的微服务架构，每个服务可能需要类似但稍有不同的配置。在 YAML 中，这种需求通常会导致复制粘贴相似的配置块，并进行细微修改。而 Pkl 通过继承和组合功能，更优雅地解决了这一问题。
// Base application config with shared defaultsclass AppConfig { port: Int = 8080 logLevel: String = "INFO" timeout: Duration = Duration.seconds(30)}// Specific service configapi = new AppConfig { port = 3000 timeout = Duration.minutes(2)}我们真的需要另一种语言吗？对 Pkl 的一些保留意见值得探讨。首先，即便是领域特定语言的引入，也不可避免地增加了学习成本。每个新团队成员都需要学习 Pkl，每个工具链都需要适配它，每个 CI/CD 管道也需要支持它。对于配置这样基础的任务来说，这无疑增加了许多摩擦。
JVM 集成也引发了一些担忧。虽然 Pkl 自称轻量，但如果需要一个 JVM 运行时来管理配置，对于那些简单服务或容器化环境来说，这显得有些麻烦。在这样的环境中，每一兆字节的资源都弥足珍贵，这种需求可能成为 Pkl 被采用的障碍。
另一个值得注意的问题是苹果的长期承诺。苹果曾推出过多款开发者工具，但随后又放弃支持（还记得 WebObjects 吗？）。虽然 Pkl 是开源项目，但它的开发显然以苹果为主导。如果苹果不再对其感兴趣，社区力量或许不足以维持其发展。
Pkl 的语法虽清晰简洁，却引入了另一种新的配置方式。当前，市场上已有 YAML、TOML、JSON5 和 HCL 等多种格式，每种格式都曾试图解决配置问题，如今又多了 Pkl。这种碎片化可能并不会让配置管理更轻松，反而可能加剧混乱。
Pkl 的验证功能固然强大，但这类功能完全可以通过 JSON Schema 或 OpenAPI 规范实现。而这两者已经在业界得到了广泛的应用和支持。Pkl 是否真正解决了现有工具无法处理的问题，仍需进一步探讨。
从苹果自己的生态系统来看，有趣的是它们目前主要依赖 Information Property List 和 JSON 进行配置。如果 Pkl 真是一个重大的改进，为什么它没有在苹果的产品中得到更广泛的应用？
这些顾虑并非要全盘否定 Pkl 的创新性，而是提醒我们在决定采用时需要慎重，尤其是当项目的复杂性并未达到像苹果那种规模时。
我同样对 Pkl 在企业级场景的适用性持保留态度。大公司通常对新语言和工具的引入有严格要求。即使 Pkl 是苹果推出的，要让企业的安全团队批准这一新配置语言，也会面临不小的挑战。对于很多企业来说，权衡风险与收益，最终可能觉得现有的解决方案 —— 尽管不完美 —— 更安全和可靠。
结束语配置管理领域长期以来由设计于数十年前的格式主导，缺乏创新。Pkl 的出现是一种积极的新尝试，它承认了配置从简单键值对到复杂任务关键代码的演变趋势。
