苹果发布新编程语言 Pkl，国产配置语言如何应对？

在过去的 50 年里，编程语言领域经历了巨大的变革和发展，涌现出了许多具有里程碑意义的编程语言，如 C、Java、Python、Go 和 Rust 等。然而，随着技术的不断进步和应用场景的多样化，人们对编程语言的需求也在不断变化，包括面向各自特定领域的编程语言等。

最近，苹果公司就推出了一种名为 Pkl 面向配置的新型领域编程语言，致力于解决配置复杂化比如配置重复和错误验证等问题，主要面向云原生和应用配置等场景，其技术产品整体的主要目标可以概括为

Pkl 作者宣称，Pkl 从 2018 年从苹果内部发起研发并于 2024 年开源，一经发布就登上了海内外各内容渠道的头版头条比如 Hacker News、Reddit 编程语言分区，在苹果开发者分区等论坛近一周也激起了不少的关注与反馈，有支持的，有反对的，这无疑对 Pkl 项目 GitHub 关注起到了很大的作用，国内也有许多媒体都对 Pkl 相应的博客内容进行了相应的内容转载。

从 Pkl GitHub 仓库可以看出大多数早期的关注者的画像主要集中为 iOS、Android 开发者，这与 Pkl 项目一开始在 Reddit 苹果开发者板块进行发布和 Hacker News 有些帖子以 Apple releases……开头有很大关系。并且 Pkl 项目整体采用 Java 和 Kotlin 研发同样会吸引潜在的 Android 开发者。Pkl 开源之后也将主要场景集中在云原生比如 Kubernetes 配置领域，因此也吸引了一批云原生相关从业者的关注。

此外，苹果本身的品牌效应，以及之前开源 Swift、LLVM 等 "珠玉" 开源项目，还有广大的苹果开发者生态也是助推 Pkl 有如此大热度的原因，虽然这是语言技术和配置交汇的领域，有一定的技术门槛且需要面向开发者积累生态资产和提升开发者体验。我们看到 Pkl 语言开源的核心研发者其实只有三个人，但这并不意味着 Pkl 是一个 "玩具" 或者 "日抛" 项目，项目本身的完成度还是挺高的，但后续通过开源来完成长期的影响力建设和开发者生态任重道远。

同样作为面向云原生领域的配置策略语言 KCL 的核心维护者以及相关从业者，Pkl 的发布也同样引起了我们的关注。实际上早在几个月前，KCL 项目和我个人就收到了来自苹果公司职员的关注。虽然 KCL 被海外大厂的关注也不是什么神奇的事情，但是考虑到苹果不是一个典型的搞云原生和开源的公司，于是抱着好奇的态度我仍然对这个人进行了回关并浏览他的 GitHub Star 记录，发现他经常关注一些编程语言和云原生相关的项目，这不由得让我心中窃喜幻想苹果是不是能成为 KCL 的用户。😄

然而事与愿违 😢，很快他便作为 Pkl 的核心作者对外正式发布了 Pkl 项目，我的愿望就此破灭。不过就此可以看出， Pkl 作者在开源之前显然是 “有备而来”，不仅在开源之前他们已经在 GitHub 上工作并准备了三个月 (当然开源之前 commit 记录可以看到但是具体内容在开源之后就看不到了)，此外他们充分分析并评估了领域内的 "玩家" 并作了针对性的宣传。当然，我个人还是十分喜欢 Pkl 的宣传方式：比较中肯，并无特别夸大或者贬低其他项目的成分。Pkl 是很好的开源项目，维护者也是很好的开源作者。

当然不出意外的 🙀，KCL 也被 Pkl 作者在其 GitHub 讨论页面提到了，并被列到与其他配置语言比如 HCL、CUE、Jsonnet 和 Nickel 等语言的比较列表中。

KCL 和 Pkl 虽然都作为一门配置领域编程语言，但是它们在具体的项目定位、语言设计理念、使用场景和技术上仍然有较大的不同，并且他们在各自的业务场景和技术领域上都有进一步发展和提升的空间。

两个语言的设计理念可以从各自官网的 Slogan 窥见一二：Pkl 的 Slogan 是 Programmable, Scalable 和 Safe；KCL 的 Slogan 是 Mutation, Validation 和 Abstraction。可以简单理解为，KCL 相比于 Pkl ，更聚焦在云原生领域中的具体场景问题，比如复杂性和安全等，并更加贴近云原生的描述方式 (Mutation 和 Validation 取自 Kubernetes 中的 MutationWebhook 和 ValidationWebhook, 使用抽象 Abstraction 来对抗复杂性问题)。

Pkl 对于非领域内的问题尽可能收敛语言自身的设计，减少一些不必要的设计并针对特定领域进行增强，以在满足功能以及开发者使用简单的基础上。Pkl 尽可能参考一些使用起来比较简单的语言如 Python、Go 等语法语义风格，排除非预期的特性和副作用，比如从语言技术和 GitOps 结合两个方面加强对稳定性和一致性的保证，通过语言的自动化 API 来提升效率，通过强不可变性、冲突监测保证配置的确定性，通过代码复用和抽象结合默认值填充的方式屏蔽用户侧细节感知，通过自定义的校验表达式支持对配置数据的业务校验等，通过与更多的云原生工具或者项目集成比如 Kustomize, Helm 和 Crossplane 等来完成更多的场景功能支持。

而 Pkl 比在设计层面相比 KCL 更加 “通用” 和 “现代”，这不仅体现在语言设计元素上，还体现在具体的语言特性上。

Pkl 首先被设计为是图灵完备的，整体语言设计更像 Swift 和 Kotlin，这意味着 Pkl 不仅可以被用于主业 "配置" 场景，还可以做的更多。比如你可以用它来写 Leetcode 算法题、编写快速排序，甚至你可以在 Pkl 中看到像 Java 那样面向对象特性的一系列关键字以及在其他常用通用编程语言中不常见到的管道运算符 |>。此外，Pkl 的很多特性和工具也都是 Pkl 自身实现的，这一定程度上体现了 Pkl 的能力。当然这样的用例有很多，无法在这里详尽一一列举。

我本人是十分喜欢 Pkl 这样具有更多现代特性的语言的，这意味的它功能很强大，几乎不会出现满足不了的业务场景，对写库的开发者来说会比较容易接受。但是从反面的角度来说，这无疑为一门领域语言带来了额外的复杂性和推广学习门槛。

而 KCL 会在配置数据和强大的通用语言特性之间把握一个平衡，比如 KCL 没有像 Pkl 那样的过程式 for 循环；KCL 虽然提供了偏面向对象的语言特性，但并不会引入像 Pkl 那样复杂的继承链和多态；并且 KCL 又参考了一些函数式语言，它的函数被设计为 "纯" 的，不会带来额外的副作用，这使得 KCL 可以在完成复杂功能的同时又可以像 JSON、YAML 等数据那样被上层业务系统集成实现以更多的自动化。这意味着 KCL 会舍弃最复杂的极端场景而选择比较场景的场景，并针对常用的场景提供了许多内置库函数可以使用。

综合来看，KCL 和 Pkl 都支持变量定义、引用、类型定义，但支持程度和语法语义有差异；基本都支持支持常用的算术、逻辑、循环推导式、条件、函数、标准库和导入第三方模块等编程语言特性，支持方式及语法也各不相同，但都有从通用编程语言借鉴吸收；在用户自定义类型、面向对象的特性上部分支持或混合支持；在数据文件集成方面，KCL 和 Pkl 可以直接导入 JSON/YAML 数据类型和 JSON Schema 和 Kubernetes CRD 等类型定义。

此外，KCL 和 Pkl 都在配置操作 Patch, 数据验证和安全合规层面内置了许多语言特性满足配置的场景需求，比如支持配置的自动合并特性以及字段范围、类型、正则表达式等检查特性。不同是，KCL 采用了偏面向对象的特性，将数据的类型检查和约束检查分离，可以使得 KCL 提供更多的静态分析能力以满足 IDE 或者其他工具链需要合并或者组合约束检查的能力，而 Pkl 需要将约束定义与其类型定义书写在一起并统一在运行时完成类型检查和约束校验。

在开发者工具方面，Pkl 和 KCL 都是重视 Developer Productivity 的项目，提供了非常多的语言工具和 IDE 插件支持。除了基本的语言工具，Pkl 官网主要提供了三种 IDE 插件支持，分别是 IntelliJ、NeoVim 和 VS Code。巧合的是，KCL 目前也是提供了这三种 IDE 插件支持，不过它们的功能和侧重点略有不同。

Pkl 由于项目本身是 Java 和 Kotlin 开发的，因此非常容易适配到 JetBrain 系列 IDE 插件体系中，因此 IntelliJ 插件支持最为完善，而 Pkl 本身并没有提供 Language Server，因此 NeoVim 和 VS Code 插件仅基于 Tree Sitter 解析器生成器提供了最基本的高亮和代码折叠，并无更高级的定义跳转、代码重构和补全等功能。另外 Pkl 虽然作为苹果的项目，但是没有使用 Swift 开发 Pkl 也没有为 XCode 开发 Pkl IDE 插件。

而 KCL 的情况正好相反，KCL 项目是 Rust 开发，并提供了 Language Server 支持，因此可以比较容易扩展集成到除 VS Code 的 IDE 插件支持包括 NeoVim 以及一些其他新兴的支持 LSP 的 IDE 或者编辑器。并且 KCL 基于 Language Server 提供了完整的代码高亮、补全、跳转、重构、补全和快速修复等功能。由于 IntelliJ 仅在在其专业版中提供了阉割的 LSP 支持，因此我们针对 IntelliJ 插件也补充了相应的功能 Java 实现支持，但是相比于 VS Code KCL 插件功能上目前没有那么完善，还有较多的提升空间。

总之，Pkl 和 KCL 在 Developer Productivity 方面也都有提升和完善的空间，由于不同 IDE 插件实现上的差异，这块需要更多从开源社区借力不断完善 IDE 体验和场景工作流程。

为了将配置语言更好地集成到用户的应用中，Pkl 提供了 Java、Kotlin、Swift 和 Go 四种多语言的绑定。又比较巧合的是 KCL 也提供了四种 SDK 💦， 分别是 Go、Python、Java 和 Rust。

有点诧异的是，在 Pkl 开源之前，KCL 是为数不多甚至是唯一官方提供了多种 IDE 插件和多语言绑定的配置语言，并且这是在社区用户和研发者的共同敦促和努力下一点一点积累出来的。Pkl 在核心维护者这么少的情况下一开源就提供了许多可以和 KCL 对标的特性，可以想到在背后也迭代了相当久的时间，付出了相当多的努力，值得点赞。

受限于篇幅，以上内容不足以描述全部的设计细节和功能对比，下面仅列出一个表格对比用于读者参考 (截止 2024 年 2 月)，后面会出更多的文章进行详细解读，也欢迎大家参与到 KCL 开源社区与我们详细讨论。

虽然仍不清楚为什么苹果在这个时间段开源一款配置领域语言，但细想又是非常合理的事情。编程语言经过了 50+ 年的发展，并且在近十年之仍然诞生了像 TypeScript、Swift、Go、Rust 等很多通用编程语言以及以 HCL 为代表的领域编程语言。而苹果作为全球顶尖软件技术和开发者生态等的引领者，作为通用编程语言的 Swift 等已经能够覆盖重量级的工业软件开发，再配合以 Pkl 配置语言可实现对全部软件技术栈的定义，就形成了一个完美的闭环。

此外，作为相关配置和策略编程语言以及面向云原生领域和 DevOps 相关的从业者，我个人深知其中的“既要，也要和还要”，因为不论是通用语言也好还是领域语言也好，让更多的开发者使用并解决他们的问题才有意义，更进一步则是让更多的开发者用得好，用得舒服。领域编程语言对我们意味着：既要理解领域的问题，又要理解其中的编程语言实现技术，还要承担和成为开发者之间对话的桥梁和沟通语言。

目前配置编程语言仍在主流视线当中，而我们作为该领域的早期实践者在 KCL 语言方面也已经积累了很多场景案例和经验。未来，我们不仅需要做深 KCL 面向的云原生配置和策略领域，或许同时可以参考借鉴苹果的 Swift+Pkl 组合中我们缺少的通用编程语言部分，面向开发者不断提升体验和积累生态资产。不管是从 Swift 所代表的通用语言出发，还是从 KCL 代表的配置领域语言出发，打通二者的任督二脉方能实现指数级的组合效应。

编程语言是软件业的工业母机、编译器技术是信息产业的根技术，各种编程语言被用于操作系统、数据库管理系统、网络服务、工控设备、应用程序等的开发，渗透到了所有现代产业和服务领域。尤其是信息产业创新空间的持续扩展、系统复杂度的持续上升、开发成本的持续降低，都直接受益于不断涌现的编程语言和编译技术。

在编程语言这个领域国内虽然起步较晚，但是依然有不错的发展态势。在 QCon 上海 15 周年大会上，国内编程语言从业者自发成立了 PLOC 编程语言开放社区，国内该领域内的第一本《国产编程语言蓝皮书 -2023》的编写也从社区氤氲而生，同样国内在围绕编程语言上下游生态也有很多项目取得很大的突破。比如基于 OpenSumi 的云 IDE 框架构建的 CodeBlitz 已经为开放原子 AtomGit、阿里云 Codeup、支付宝小程序云、Gitee、GitLink 等代码托管平台提供在线代码编辑能力，和众多本土编程语言也存在巨大合作空间。

苹果发布 Pkl 语言对 KCL 是一个挑战，更是一个机遇——我们已经处于这个行业探索前沿。未来希望有更多对基础软件领域有兴趣的小伙伴能够加入共建开放生态。

砍掉百万行代码，这些巨头玩不转超级应用了？

4 秒处理 10 亿行数据！Go 语言的 9 大代码方案，一个比一个快

周鸿祎首堂AI课引争议，专业性错误遭质疑；智联招聘被“挤崩”，网友：找工作更焦虑了；马斯克起诉OpenAI，要求开源 | Q资讯

阿里最新图生视频模型效果好得可比肩 Sora，但 0 代码“假”开源让国内外网友骂翻了天？