tl;dr Typelevel 正在分叉 Scala；我们呼吁 Scala 生态系统中的所有利益相关者合作创建一个独立的、非营利的、开源的基金会，以维护整个 Scala 社区的利益。社区赞助的#Scala 工具链分支会有多少兴趣？请转发和收藏。 — Miles Sabin (@milessabin) 2014 年 8 月 25 日 它在 Twitter 和私下都引起了热烈的反响。反应有时令人困惑，但通常很兴奋，而且总是积极的。我想在这里做的是为问题提供一些背景，并勾勒出肯定答案所导致的方向。随着 Scala 社区的成熟，该语言出现了许多不同的发展方向，LAMP/EPFL Dotty 编译器专注于提供 DOT 演算的实际实现。 Scala.Meta 系统旨在为各种 Scala 编译器提供可移植的元编程工具。
Scala 编译器的多个研究和私有变体正在开发中，并被各种学术和商业组织使用。 IDE 提供了它们自己的 Scala 变体，这些变体或多或少准确地近似于 Typesafe Scala。其中，针对 JVM 的唯一编译器在近期内普遍适用于整个 Scala 社区，是 Typesafe Scala 编译器。该编译器 2.12 版本的当前路线图将于 2016 年初发布，目标非常温和，与 Typesafe 的重点一致。除此之外，Next Steps 路线图提到了许多令人感兴趣的事情，但很明显，这些事情还有很长的路要走——最早要到 2017 年才能看到曙光。 Typesafe 专注于稳定性和 Java 8 兼容性的动机很容易理解。 Typesafe 是一个商业实体，其产品在基于 JVM 的企业中间件空间中销售。它的主要软件产品 Akka 和 Play 可能是对 Java 最友好的任何重要的 Scala 项目，简单的算术应该告诉你，这些（以及相关的咨询公司）的潜在客户中有很大一部分（可能是绝大多数） 、培训和支持）主要是拥有全部或大部分 Java 代码库和开发团队的 Java 企业。在这种情况下，应该很容易看出，对他们来说，强调 Scala 作为 Java 的补充，而不是作为其继承者，是最重要的。虽然这是完全合理的，并且满足了许多人的需求，但是 Scala 社区的核心中有一个重要的支持者，他们的需求没有得到完全满足。这个选区是 Scala 社区的一部分，他们更加重视类型化的函数式编程风格，并且对 Scala 之外更广阔的世界中函数式编程的当前发展有着浓厚的兴趣。在 Typelevel 保护伞下聚集的项目是该选区的主要例子。作为这些项目和其他项目的生产者和消费者，我们不断发现自己遇到了当前 Scala 的局限性。有时，这些限制很小，可以通过简单的解决方法来解决，其中许多已经成为 Scala 的民间传说。其他限制更为严重，只能通过繁琐的编码或其他复杂且令人困惑的 hack 来解决。不幸的后果是，重要问题的优雅解决方案被层层叠叠的残骸所掩盖，这些残骸只是为了回避当前编译器的怪癖。更令人沮丧的是，其中许多限制相对容易消除。其中一些的修复纯粹是语法上的——例如，对 Scalaz 及其用户非常重要的类型构造函数部分应用程序具有笨重的编码（“类型 lambdas”），它可以提供一流的语法支持，而不会影响 Scala 的语义和以完全二进制兼容的方式。类似地，对文字值的单例类型的语法支持（参见 SIP-23）对 shapeless 和 Spire 及其用户具有巨大的价值。 Spire、Scodec 和许多其他公司都欢迎为 Bytes 和 Shorts 添加文字。其他修复虽然影响语义，但只会以保守的方式进行——使用 Typesafe Scala 编译器编译时有效的程序在使用修复进行编译时将具有相同的含义和二进制表示。
考虑到这一点，我们打算创建一个新的 Scala 发行版，作为 Typesafe Scala 编译器的保守分支，重点是满足围绕 Typelevel 堆栈合并的 Scala 社区部分的需求。作为一个保守的分支，我们的目标是与 Typesafe Scala 编译器合并兼容，一个关键目标是将拉取请求（其中许多将解决长期存在的 Scala 错误或功能请求）反馈给 Typesafe Scala 编译器。我们的目标是让语言以几年前我们看到的速度继续发展，但不同的是，现在这将是一个选择加入的过程，优先级将由社区确定。当然，魔鬼在细节中。分叉编译器只是故事的一小部分——在许多方面更重要的是周围的库生态系统。作为该计划的一部分，我们打算至少发布 Typelevel 库的兼容构建——以我们的 Typesafe 社区构建（它试图通过构建一系列社区库来跟踪生态系统随着时间的推移随着时间的推移而发展的 Scala 编译器的一致性） ) 和 Scala.js（已将一些重要的社区库移植到其编译器中）。我们欢迎与我们有共同目标的所有其他各方、个人或组织的参与——无论是那些想要为编译器的开发做出贡献的人，还是那些希望他们的库和框架成为 Typelevel 社区构建的一部分的人。现在还为时尚早，但我们希望有足够的热情参与，我们将能够在年底之前生成有用的二进制文件。正如我之前所观察到的，该语言已经存在多种变体，很长一段时间以来，很明显社区的不同部分有不同的兴趣。我们不应该害怕承认这一事实——试图忽视它会（可以说已经）适得其反。相反，我们应该将多样性视为健康和充满活力的平台和社区的标志。我们没有资源或专业知识来实现这一目标。我们不同意——围绕 Typelevel 项目的社区包含许多地球上最有能力的 Scala 程序员。在我们之间，我们对 Scala 的类型系统和其他语义（无论是指定的还是实现的）、一般的编译器构造以及特别是 Typesafe Scala 编译器内部结构都有深刻的理解。我们非常熟悉 Scala 工具链，我们中的许多人多年来一直在日常工作中大规模使用它。我们也非常熟悉我们寻求解决的问题——它们是我们每天面临的问题。我们还有其他 Scala 编译器变体的存在证明。从事这些项目的全职人员数量确实非常少——我们相信，在实践中，一个开放、包容和热情的开源项目可以匹配或超过这一点。
不，我们真的没有。我们完全期望这是整个演习中最具挑战性的部分。也就是说，我们受益于 Scala 二进制兼容性问题的多年经验，现在我们知道将社区构建样式模型与有效使用迁移管理器（已经是 Typelevel SBT 插件的一个组件）相结合是在掌握问题的关键方面非常有帮助。这里存在真正的风险，需要小心。不过有一件事是肯定的——如果我们不尝试，我们永远不会知道它是否可能。当然，将我们自己限制在与 Typesafe Scala 编译器合并兼容的更改上，这对我们可以做的事情施加了相当严格的限制。许多非常理想的变化远远超出了范围，有些人想要探索这些可能性。我们认为这是完全合理的，我们不认为两者是相互排斥的——一个合并兼容的 Typelevel 编译器满足了我们的许多紧迫需求，但我们希望让人们能够像 Scala.Meta 所做的那样进一步推动，Scala 虚拟化和 Dotty。我们相信，有助于合并兼容的 Typelevel 编译器与 Typesafe 编译器保持接近的相同基础架构（社区构建，MiMa）也将对想要尝试更激进更改的人有很大帮助。至少，社区构建基础设施将使人们不仅可以使用带有裸编译器的编译器，还可以使用一组核心兼容库。我们相信这样的基础设施也会使 Scala Virtualized、Scala.Meta 和 Dotty 受益。这让我进入了本信息的最后一部分。我们已经很清楚，Scala 生态系统中有许多不同的利益相关者，他们既有共同的利益，也有不同的利益。这是好事，是我们应该共同努力支持的事情。为此，我们认为是时候成立一个独立的、非营利的、开源的基金会来维护整个 Scala 社区的利益——我们呼吁所有希望看到 Scala 生态系统蓬勃发展的组织和个人加入我们的项目。除非另有说明，所有内容均根据知识共享署名 3.0 未移植许可进行许可。
返回博客