IBM 近期终止参与服务器端 Swift 的推进工作。IBM 自 Swift 开源以来就参与其中，IBM 现在已放弃在 SSWG（ Swift Server Work Group ，Swift 服务器工作组）中的领导地位。这将对 Swift 及 Swift 社区将产生什么影响，InfoQ 就此采访了 IBM 的 Chris Bailey。
IBM 的这一决定于 2019 年 12 月公开发布在 Swift 邮件列表中，该决定立刻在 Swift 及 Y Combinator 、 Reddit 等相关开发人员社区中引发强烈反响。人们给出了多方面评论，做出了各种猜测，涉及 IBM 的声明对服务器端 Swift 开发的可能影响，以及导致 IBM 做出如此决定的根本原因。
一些开发人员猜测是由于 Vapor 的发展壮大动摇了 IBM 在此领域的影响地位。Vapor 是 IBM 服务器端 Swift 开发框架 Kitura 的主要竞争产品。也有人指出，是由于 Rust、Go 等新兴语言在服务器端表现比 Swift 更为成功。一些人甚至预言服务器端 Swift 将走向终结。当然，兼听则明，也有人发推文表达了对服务器端 Swift 的信心。
为深入报道实情，InfoQ 有幸采访了 IBM 前高级技术委员会成员 Chris Bailey。Bailey 主要关注 Swift 的运行时技术，他和 Ian Partridge 这两位 IBM 贡献者一并退出了 SSWG 工作组。
InfoQ：请介绍一下您过去参与服务器端 Swift 项目的情况，以及您的主要贡献。
Chris Bailey：我本人及 IBM 团队自 Swift.org 项目开源发布以来就参与其中。在前期，我们侧重于支持可用于 Linux 等服务器环境的 Swift 语言核心和 API。我们的工作包括 Swift 语言本身、Dispatch 并发库和 Foundation API 库等。所有这些构成了 Swift 运行时。由此，我们创建了 SSWG 工作组，凝聚致力于服务器框架的各个社区，并基于通用的核心库开展协作，扩展服务器系统生态。
不仅是 Swift.org 社区，我们还创建了 Kitura 框架及相关的软件库和工具，形成了围绕 Kitura 构建的生态。该生态提供完整的微服务框架，支持运行云原生应用所需全部特性。
InfoQ：Kitura 作为一个完善的框架，多年来已具有 70 多位贡献者，完成 163 次版本发布。对于那些在您和 Ian Partridge 离开项目后坚持使用 Swift 的开发人员，您是否依然强力推荐 Kitura？
Bailey：Kitura 每日有上千次的下载量，一些大型企业也在生产环境中使用，其中不乏公开宣称是 Kitura 使用情况者。
IBM 依然通过所有现有的商业协议支持 Kitura，不过我们正在逐步减少对新功能继续开发的贡献。这为广泛的社区参与提供了更多的空间和机会，我们正在努力使社区中感兴趣的各个参与者能够使用这项技术。与其它所有的开源项目一样，Kitura 的长期成功取决于围绕其形成的活跃社区，并且用户也愿意为他们所使用的技术做出贡献。
我希望这将引导 Kitura 更趋向于成长为一个社区引领发展的项目，进而继续发展壮大。
InfoQ：在 Linux 平台上的 Swift 现状如何？在您看来，Swift 要在 Linux 平台上占据一席之地，还需要做哪些工作？
Bailey：Swift 屹立于巨人肩膀之上，它的确是一项伟大的技术。作为一种新的语言，Swift 的设计和构建是基于对前期语言的充分了解，并博采其它语言之长。
Swift 本身很好地支持在服务器端使用。Swift 起源和聚焦于移动设备端，这意味着 Swift 具有内存占用较低、启动快速的优点。这两点对于服务器端运行同样非常重要。
一直以来，Swift 的最大问题在于它是否能跳出一种 iOS 移动开发人员用于对移动应用构建全栈前端（BFF）的技术，进而作为一种通用服务器技术应用于更广阔的应用领域。
作为 Apple 生态系统中的嵌入式技术，Swift 从中受益匪浅。此外，在服务器生态系统所需要的功能方面，它对 Apple 有很多依赖，这对它的有机增长带来了很多的挑战。例如，几乎所有 Swift 开发人员都使用 Apple Xcode 作为 IDE，它对 iOS 设备开发提供出色的支持，其中包括在模拟器环境中提供本地运行的功能。如果 Xcode 能添加对编写服务器端代码的支持，那会更好。这样开发人员可以通过简单集成 Appsody 等开发工具到 Xcode，直接从本地 IDE 对容器环境做开发。一旦在社区中形成了开放式治理和开放式生态，人们就可通过做出贡献去解决对自身非常重要的问题和用例。
Apple 公司正努力解决这些问题，支持更开放的 Swift，助力构建服务器生态系统，并在近期加快了步伐。Tom Doron 一直致力于领导 Apple 公司通过 SSWG 工作组推进服务器端生态系统。此外，Ted Kremenek 最近在 Swift 论坛发文“通往 Swift 6 之路”（ the road to Swift 6 ），阐述了逐步扩展生态系统并使其更开放的强烈意愿。文中提及进一步侧重于新兴的语言服务器协议（LSP，Language Server Protocol）项目，以支持更多 IDE 进而推动 Swift 的发展。
InfoQ：在服务器端领域，继Swift 和 Kitura 推出以后，服务器端原生语言领域经历了 Go 和 Rust 的兴起。尤其是 Rust，至少在专注于安全方面，应该是 Swift 的直接竞争对手。您如何看待这些语言技术栈之间的对比？
Bailey： Go、Rust 和 Swift 经常被一并归类为“现代原生语言”（Modern Native Languages）。它们都是编译型的类型安全原生语言，视为 C/C++ 语言的现代替代语言。
作为一种编程语言，Swift 非常年轻。它于 2014 年中首次出现，但正式支持 Linux 的开源项目是直到 2016 年 9 月（仅三年半前）才作为正式项目发布。相比之下，Go 项目和 Rust 项目分别已经存在了 10 年和 9.5 年，这意味着这两种语言具有明显的先发优势。
作为一种系统语言，Go 正在应用于云技术的核心基础设施（如 Kubernetes），并且可用于 CLI 的开发，因此形成了真正的市场。Rust 在一定程度依然在确定自身的市场定位，但是 WebAssembly 的发展推动了对它的更多关注。显然就采用曲线而言，Swift 稍为落后。
我在去年的 AltConf 大会上报告了服务器端 Swift 联盟的现状，给出了服务器端 Swift 的当前采纳程度。我在报告中比较了同一发展年龄段上 Swift 和 Node.js 软件包生态的规模。尽管在相同年龄段上 Swift 落后于 Node.js，但目前已与大家所期待的相差无几。
从根本上看，服务器端 Swift 潜力巨大，我非常期待其未来成功发展并得到广泛采用。
服务器端 Swift 的官方论坛提供项目的进展情况。InfoQ 将继续为读者提供相关最新关注资讯。
原文链接：
评论