这是我很久以来一直想写的帖子。我意识到，当涉及到这个话题时，我完全是有偏见的。我对看到SWIFT在服务器上取得成功抱有大量潜在错位的乐观情绪和既得利益。但我也相信，我比大多数人都有更多的洞察力，因为我是全职从事这项工作的。我也希望这篇帖子能引起很多讨论，所以嘿，推特，Reddit和黑客新闻👋。
当我从ServerSide.swft会议回来时，我第一次想到要写点什么。对于那些没有听说过ServerSide.swft的人(我是组织者之一)，ServerSide.swft是SWIFT on the Server的一个国际会议(没有什么令人惊讶的地方)。它是一个社区中的每个人都可以聚集在一起的地方，因为它的重点是服务器。这是一个很棒的地方，可以找到非常技术性的讲座，比如GRPC和测试NIO系统。这是一次令人敬畏的会议，令人惊叹的演讲者阵容，社区周围真的是一片沸腾。最近，我辞去了正式的工作，转而全职从事SWIFT服务器端的工作，我对此感到相当满意！
一个月后，IBM悄悄地宣布，他们将放弃SWIFT作为他们的开源语言之一。这对社区来说是一个巨大的打击，特别是每个使用Kitura并投资它的人。除此之外，IBM没有发表正式声明的方式给许多人留下了不好的品味。
看到IBM在服务器领域退出SWIFT，真是一件令人羞愧的事。竞争总是好的，IBM应该记住他们为使服务器端SWIFT可行而投入的大量工作。消息公布后，有很多人和文章认为这是服务器上的SWIFT死了的信号。毕竟，如果IBM不能让它工作，为什么还会有人使用它呢？
需要说明的是，我并不是说在服务器上使用SWIFT时一切都是完美的。有一些初期的问题和问题产生于它的不成熟。在Linux上进行开发、崩溃处理、缺乏操作系统支持、调试、SwiftPM特性--所有这些都给我们带来了障碍和问题。直到最近，如果你不想弄脏你的手，可以说，我不会推荐在服务器上使用SWIFT。
然而，自1月份以来，出现了一些重大事态发展，显示出对未来的真正希望。首先，在1月底，泰德·克雷梅内克在论坛上发布了关于斯威夫特6号之路的帖子。这不是SWIFT 6的路线图，而是服务器路线图上的SWIFT。SWIFT 6的每个目标要么与服务器相关，要么直接受益。比如新的操作系统支持、LSP改进、构建时间和依赖项管理改进。清单不胜枚举，我甚至还没有提到真正的并发模型的目标，对我来说，这是SWIFT在服务器上缺少的最后一件东西。
为了表明这一切的重要性，SWIFT核心团队有了两名新成员。负责SWIFT NIO和SWIFT服务器工作组的Tom Doron和几乎单枪匹马将SWIFT拖入Windows的Saleem Abdulrasool。拥有这两个核心团队意味着在苹果生态系统之外的SWIFT对SWIFT团队的重要性。
几天后，米沙尔·沙阿(Mishal Shah)在论坛上宣布，斯威夫特将提供夜间码头图片。虽然这不会影响大多数开发人员，但它很重要。它允许您测试SWIFT和Foundation中的更改，而无需编译SWIFT或安装新的工具链。因此，框架开发人员现在可以毫不费力地针对SWIFT的预发布版本测试代码。
它还建立在SWIFT for Linux的月度版本的基础上，而SWIFT for Linux已经持续了一年多的时间。最初是从SWIFT 4.2.2开始的，它为快速获得Foundation的修复程序开辟了道路，而不是等待下一个Xcode版本。令人惊讶的是，这是一个Linux比MacOS更快发布SWIFT版本的案例！
在夜间Docker Images发布消息一周后，科里·本菲尔德(Cory Benfield)在dotSwift的舞台上宣布发布Swift Crypto。Crypto是您真正想要的任何服务器生态系统的一部分。滚动您自己的Crypto不是一个好主意，并且链接到OpenSSL会导致问题。很难从所有不同的操作系统与OpenSSL集成。依靠系统提供的OpenSSL将在任何合理的时间范围内阻止SWIFT支持HTTP/2和HTTP/3。
SWIFT Crypto仍然不会没有它的问题，这是意料之中的。目前，SWIFT Crypto既不支持RSA密钥，也不支持PEM/DER密钥。这在服务器世界中95%的用例中都是有问题的！😅当前的解决办法是嵌入您自己的BoringSSL副本并自己使用。(以及需要这些功能来嵌入自己的BoringSSL副本的每个依赖项。)。这再次归因于SWIFT的不成熟，SWIFT加密团队将在未来修复这一问题。
但好消息不断传来。本月早些时候，论坛上宣布了针对SWIFT的Google Summer代码项目。在宣布的四个项目中，有两个直接致力于服务器端和Linux的改进。
最后，第二天Tom Doron宣布支持更多的Linux发行版。这是SWIFT向前迈出的一大步，因为它使您可以更轻松地在您已在使用的操作系统上运行SWIFT。许多公司都有围绕不同操作系统构建的基础设施和工具。通过将SWIFT限制为只能使用Ubuntu(Docker除外)，这意味着这些公司不能使用它。现在他们可以了，在对Amazon Linux的支持下，它甚至为Lambda这样的东西打开了机会。
为了配合这一声明(无论是不是巧合)，亚马逊发布了他们的Smoke Framework 2.0版。看到像亚马逊这样的公司全力以赴在服务器上使用SWIFT，真的很酷。如果你想了解更多信息，请查看ServerSide.swft网站上西蒙的视频：
虽然上面的一切对服务器来说都是好消息，但也有一些非服务器用例开始进入市场。最大的是TensorFlow的SWIFT。使用SWIFT进行机器学习似乎是一个奇怪的选择，而Google选择SWIFT作为他们的主要ML语言之一就更奇怪了！但选择它是有充分的理由的。Tryolabs最近深入研究了这样做的原因、背景和好处，这是一本很棒的书！即使这可能不适用于你(当然不适用于我！)。它提供了两大好处。
首先是改进语言本身。S4TF团队需要对SWIFT和编译器进行一些重大更改，以实现可区分编程和Python/C++互操作性等功能。我们现在看到这些变化正在上游并入SWIFT本身，在那里任何人都可以使用它们。此外，S4TF团队最近发布了SWIFT基准来对代码进行基准测试。看到斯威夫特的伟大工具在苹果之外开发，这真是太棒了！
其次，它提供了一个巨大的思想分享机会。在苹果生态系统之外使用和发展SWIFT的一个重大项目非常重要。这向外界证明了斯威夫特不是苹果的语言，也证明了核心团队希望斯威夫特不仅仅是用来编写iOS应用程序的语言。
要让SWIFT在网络上工作，但在客户端工作，还有大量的工作要做。SwiftWasm项目允许您编写SWIFT，并通过WebAssembly在浏览器中使用它。这可能意味着要为🎉网站编写SWIFT而不是JavaScript，虽然SWIFT的早期阶段和大量工作还需要回流到SWIFT中，但它显示出了真正的前景，你现在就可以尝试它了！
随着服务器端SWIFT的迅速发展，今年的速度只会加快。我猜想我们将会看到更多受支持的Linux发行版和对该语言的进一步改进。虽然我不指望斯威夫特6和异步/等待在今年登陆。Vapor4的发布是又向前迈进了一步，包含了SSWG的大量工作。SSWG还出版了一些关于构建、部署和调试最佳实践指南。这些绝对值得一看。
重要的是要记住，斯威夫特还年轻。它在2015年底才是开源的。围棋是一种新的语言，但它于2009年首次发布。铁锈是另一种引起广泛关注的语言，最早出现在2010年。斯威夫特正在迎头赶上，你在进行比较时应该考虑到这一点。无论发生什么，对于服务器上的SWIFT来说都将是有趣的一年。未来肯定是光明的！