Scala 语言创建者 Martin Odersky 以及关键库作者与维护者李浩毅描述了他们对 Scala 语言未来的规划，并希望 Scala 能在现代编程领域保有一席之地。

原文：Evolving Scala

Scala应该前进得多快？需要改进什么？语言本身是否应该改变？本文讨论了Scala必须不断进化的原因，为什么这种进化是必要的，以及我们预计这种进化将采取哪些方向。

我们希望这能涵盖许多关于Scala语言方向的常见问题，并帮助社区了解语言在未来几个月和几年中将走向何方。

摘要

尽管Scala不再像2010年代中期那样处于炒作的风口浪尖，根据大多数调查，该语言保持在主流语言列表之外。从技术角度来看，核心语言和生态系统在过去十年中得到了极大的改善。在许多方面，Scala今天的基石比十年前要好得多。

Scala一直引领着编程领域的潮流。为了换取比主流语言略逊一筹的打磨和稳定性，人们选择Scala，以便今天就能享受到下个十年的语言特性。Scala的价值始终在于这些语言特性所赋予的独特组合——安全性和便利性，以及它将面向对象和函数式编程思想融合在一起，从而优雅地适应这些特性。

但其他语言也在不断进步，因此Scala必须继续创新，在它的优势和劣势上不断改进，特别关注新用户的入门体验。当然，有一些持续存在的问题，尤其是在IDE支持以及生态系统的易学性方面，随着语言的发展，工具、兼容性和迁移成本等问题也始终会存在。但如果Scala想要在未来几年保持其吸引力和相关性，它别无选择，只能继续前进。

Scala 当前所处的位置

尽管炒作已经消退，但从普及度来看，Scala 仍然处于其一贯的位置：并不完全属于主流，但比那些更小众的语言有着更广泛的采用率。例如，RedMonk 语言排名在 2014 年将 Scala 排在第 14 位（2014年的排名），10 年后的 2024 年仍然在第 14 位（2024年的排名）。

在这段时间里，编程领域发生了显著变化：Swift 取代了 Objective C，Go、Kotlin、Dart 和 Rust 的出现，CoffeeScript 和 Perl 的衰落。然而，Scala 的位置始终保持不变。尽管社区中的个人来来去去，但整体而言，Scala 似乎保持着强大的稳定性，拥有一个坚实的爱好者基础。

技术上，Scala现在比10年前拥有更坚实的基础。生态系统已经成熟，各种反应式或纯函数式编程风格已经找到了他们的受众。像Scala Toolkit和com.lihaoyi平台这样的替代风格现在也可供选择。新的构建工具如Scala-CLI和Mill已经出现，而开发者工具如Scalafmt和Scalafix已经得到广泛应用。IDE仍然是一个痛点，但我们预计到2025年它们会有所改进。重用符号运算符的潮流已经逐渐式微。

Scala 一直处于语言前沿，证明了像 lambda 表达式、记录和模式匹配等语言特性在 10-15 年后被 Java、Python 和其他主流语言采纳的可行性。目前尚不清楚主流语言在 10-15 年后将会采纳 Scala 的哪些当前特性。

Scala 将走向何方？

在本节中，我们将讨论核心 Scala 开发者将集中精力的一些领域。

安全性与便利性：两者取其一

Scala 一直是一种混合型语言。面向对象和函数式风格的融合经常被提及。但它的另一种融合是 安全性 和 便利性。传统上，“脚本”语言如 Python 不安全但方便，而“应用”语言如 Java 安全但不便。Scala 是第一个证明你可以在同一语言中做到这两点的语言。更现代的语言如 Swift 或 Kotlin 也在这条道路上取得了进步，当 Scala 最初开始时，这种想法是闻所未闻的。

然而，过去二十年里，编程领域并没有停滞不前。曾经属于 Scala 的许多独特之处现在已成为普遍现象。所有现代语言都提供了泛型、类型推断、lambda 表达式、记录、模式匹配等特性。为了继续吸引用户，Scala 必须在这两个方向上继续创新：

1. 提升安全性而不牺牲便利性：例如 捕获检查、显式空值、安全初始化、多态等价 等特性。

2. 在不妥协安全性的前提下提高便利性：如 枚举、可选括号、命名元组 等特性。关于 聚合数据字面量 的讨论激起了广泛的兴趣，尽管目前还太早看到它将带来什么结果。

Scala 生态系统广泛且多样化，但我们认为这些双重目标是共同的主线。无论您是在 JVM 上使用 Akka 实现后端服务，通过 Scala.js 在浏览器中构建 Web UI，还是通过 Chisel 定制硅芯片，Scala 的安全性和便利性是人们选择这种语言的原因。

其他语言也在追求这些目标，但我们相信Scala做得比大多数语言都要好：它的类型系统、模式匹配、集合库、多重继承系统等都是业界领先的，即使其他语言也有自己的特色。因此，Scala能够比其他语言更好地执行和组合特性，并以一种统一、简洁和原则性的方式将这些特性结合起来，而不是临时性地拼接它们。

展望未来，Scala必须继续追求安全性和便利性的双重目标。明天的流行框架可能与今天的不同，而今天的又与几年前的不同。但几十年来，开发者们一直希望获得安全性和便利性，我们预计在未来几年这种需求将继续存在。

打磨“粗糙边缘”

Scala 已不再是新兴语言。二十年前，许多事物看似是好的想法，但并非所有决定都取得了预期的效果。尽管长期使用 Scala 的开发者可能已经习惯了这些特性，但 Scala 语言本身需要不断打磨这些粗糙的边缘：

1. 一些特性，如 scala-actors、scala-parser-combinators 或 scala-xml 已经被移除。它们现在作为独立的库存在，你可以根据需要选择使用或不使用，但已不再是语言的核心部分或标准库的一部分。其他类似的清理工作包括 Scala 2.13 集合重写。

2. 正在处理的更多问题包括：@unroll 以避免与默认参数和 case class 的二进制兼容性问题，这是实验性的（SIP-61），以及 for-comprehension 的改进处于预览阶段（SIP-62），这些改进应该有助于解决使用这些 Scala 语言特性时长期存在的问题。

3. 一些其他长期存在的问题尚未得到解决，但正在讨论中：灵活的变长参数、解包、涉及 for-comprehension 语法的一些其他问题，等等。

过去20年间，编程领域发生了巨大变化，Swift、Kotlin、Java、C# 和 Python 等语言都迅速发展。有时是发现新的方法，有时是针对常见用例收敛到相似解决方案。仅仅因为Scala在2005年做出了一个设计决策，并且我们接受了这个决策20年，并不意味着这个决策在2025年仍然是最佳的。有时，我们可以也应该做得更好。

Scala的核心一直是其面向对象（OO）和函数式编程（FP）特征的融合，以及安全性和便利性的融合，但其他一切都是可以讨论的。例如，Scala经历了三次集合库的迭代，才到达了今天的地位，尽管经历了变革，但语言也因此变得更加出色。我们今天能够解决哪些长期存在的问题，而我们在5-10年后会为此感到庆幸？我们可以从其他语言中采纳哪些特性和约定，而不是以我们独特的方式重新发明轮子？

让新手更容易上手

我们相信Scala可以变得更加容易让新入门者掌握。所有高级Scala用户在某个时刻也都是新手。你今天所听到的所有大型Scala项目最初都是由一群新手开始的：

• 大学生尝试使用这门语言来完成他们的研究项目

• Python/Ruby开发者尝试使用这门语言来提高他们生产系统的稳定性

• 想要更多灵活性、力量和快速开发的Java老手

我们支持高级用户和高级框架，但根据定义，高级用户能够自我照顾：解决他们自己的问题，编写他们自己的文档，并提出他们自己的语言变更。Scala的高级用户一直都在提交他们自己的补丁和改进——来自Akka世界的scala.concurrent.Future，部分统一，泛型元组，以及来自纯函数式编程世界的kind-projector——我们希望他们将继续这样做。相比之下，新来者必须依赖Scala的核心维护者来确保他们有一个良好的体验。

实际上，这意味着：

1. 优先支持简单易用的库，如Scala Toolkit和com.lihaoyi平台，提供代码和文档支持。

2. 将Scala语法与其他语言中不必要的差异进行对齐。已经实现了通过import foo.*进行的通配符导入和通过foo*进行的可变参数拼接，后者取代了旧的蜗牛操作符 foo@_*。

下一个重要的Scala项目很可能会由那些为了解决之前没有人想过要解决的问题而开始学习这门语言的新手发起。他们会很聪明，但不会是那些推动Scala语言极限的专家，他们也不会使用最复杂的高级语言特性或设计模式。他们会知道Java、Python或JavaScript，因为那是他们在学校里学的。这就是我们需要确保那些人能够轻松地进入Scala语言的原因。

考虑的替代方案

关于Scala应该走向何方，总是有不同的意见。我们将讨论两个在语言发展方向上反复出现的主张。

为什么不全面拥抱框架？

社区中常见的请求之一是让Scala社区全面拥抱某些框架或工具链。例如：

1. 将Scala全面作为纯函数式编程语言
2. 将IO monads作为构建应用程序的方式

这些想法值得讨论；毕竟，使用Scala进行纯函数式编程和IO单子的子社区一直健康且充满活力。然而，当更深入地分析这种做法时，存在一些问题：

1. Scala的设计初衷就是灵活且富有表现力。正如历史所证明的那样，这促进了创新：十年前，Akka 和 Scalaz 是流行的框架。Scalaz让位于更新的函数式库，如 ZIO、Cats-Effect、Monix 和 FS2。Kyo 看起来有潜力，但仍然处于早期阶段。Scala语言必须足够通用，以支持这种自然演变，而不能将自己绑定到那些随时间兴衰的具体框架上。

2. 核心Scala开发者并非框架专家。当Akka流行时，他们并非actor模型方面的专家，如今也不是IO monads方面的专家。因此，我们需要那些子社区中的高级用户为自己发声，并推动语言在社区所需方面的改进。

因此，Scala必须保持通用性，通过构建任何框架或库都能从中受益的特性。我们鼓励框架爱好者提出对Scala语言的改进建议：虽然并非每个具体想法都会被接受，但反馈会推动语言变化，从而惠及所有框架。

为什么不能冻结所有特性开发？

另一个常见的请求是“停止实现特性”。这经常在语言讨论中出现，来自对工具支持、就业市场或其他事物不满意的人。这些情绪是可以理解的。但现实中，冻结特性开发将注定导致Scala语言的衰落。

Scala 一直以来都比 Java 等语言功能更丰富，但打磨和稳定性却相对不足。Scala 的核心价值主张是，作为交换，你将获得来自未来的语言特性，而其他语言可能要过 10-15 年才能获得：

• Apache Spark 于 2014 年选择 Scala 作为在 JVM 上具有 lambda 表达式和模式匹配功能的语言。

• Akka 选择 Scala，因为它是一种简洁、高效的编程语言，支持使用 Futures 或 Actors 进行轻量级并发。

• Scalaz 和 Cats 选择 Scala，因为它是一种简洁的语言，拥有丰富的类型系统。

其他语言开始采用这些特性，给 Scala 带来了创新的压力。到 2025 年，基本上在 RedMonk top 20 的所有语言中，都包含了 lambda 表达式、模式匹配、轻量级并发和类型系统！那么，为什么任何项目会选择 Scala 呢？

Scala 仅凭稳定性和完善性是无法与主流语言竞争的，因此如果我们今天停止功能开发，Scala 最终会变成一个功能更差、完善性和稳定性更差的编程语言，并且没有存在的理由。因此，Scala 需要持续不断的改进来维持其发展，为人们和项目提供选择这门语言的理由。我们可能会犯错——没有一条保证成功的道路——但功能冻结是一条保证停滞和失败的道路。

Scala 生态系统中的开放性问题

Scala 生态系统并非没有问题。以下我们将简要介绍我们认为 Scala 当前面临的最大挑战，以及我们将如何应对这些问题。

工具：集成开发环境 (IDEs)

“工具”是上次 VirtusLab Scala 调查 中指出的最大改进领域。这主要指的是集成开发环境（IntelliJ 和 VSCode）以及构建工具（如 sbt），这些是每位编写 Scala 的人都必须与之交互的工具。

在 Scala 社区中，使用的两个主要 IDE 是 IntelliJ 和 VSCode。上述调查表明，大约 80% 的受访者使用 IntelliJ，大约 50% 使用 VSCode，还有一些人同时使用两者。

IntelliJ

IntelliJ 对 Scala 3 的支持仍然需要赶上它对 Scala 2 一直以来的支持质量。尽管如此，进展是稳步的，最近的改进显示出加速的步伐。

1. Scala 3 最近引入了“预览”功能的概念：这些功能已经从实验性稳定下来，但尚未在IDE和其他生态系统中获得支持。这是为了帮助IntelliJ和其他IDE有足够的时间跟进，以免在语言演变时落后。

2. JetBrains 现已成为 Scala 中心咨询委员会的成员。这已经改善了 JetBrains 和 Scala 编译器团队之间的沟通和协调，并有助于避免过去出现的问题，即 IntelliJ 需要时间才能跟上 Scala 的变化。

3. 最近的语言变更已经相对迅速地融入到 IntelliJ 中：SIP-64 改进的给定语法 和 SIP-58 命名元组 已经在 IntelliJ 2024.3 中可用，而 SIP-62 For 推导改进 将在 2025.1 中提供。

我们承认还有很多工作要做。IntelliJ 团队正在努力提供对 Scala 3 的最佳支持，您可以期待在未来几个月看到更多改进。

Metals - Scala 语言服务器

金属（Metals）通常与 VSCode 一起使用，但也支持其他编辑器。金属（Metals）与 IntelliJ 相比面临不同的挑战：它始终使用实际的 Scala 编译器来进行代码智能，因此始终与实际语言保持同步。但它曾遇到过稳定性问题（例如 #6478），其中一些问题源于其多进程架构的复杂性，另一些则源于其与 Scala 3 的新集成（例如 #6628）。金属（Metals）的维护者目前正在专注于修复最突出的问题，但如果您在自己的代码库中发现了任何问题，请打开 https://github.com/scalameta/metals/issues 上的问题，VirtusLab 团队将乐意查看（必要时甚至签署保密协议）。

Scala 3 编译器的开发者已经广泛使用 IntelliJ 和 Metals，我们也清楚开发者在使用这两个 IDE 时所面临的问题。我们将继续在发现问题时进行报告，并与 IntelliJ 和 Metals 的维护者合作，以改善编译器与 IDE 之间的集成。但我们也需要社区人士积极参与问题报告，以便 IDE 维护者能够进行调查和修复。

构建工具

构建工具 sbt 的复杂性在过去十年或更长时间一直是 Scala 社区的一个长期问题。然而，我们认为隧道尽头已经出现了曙光：

1. Scala-CLI 已变得流行。现在它是默认的 Scala 启动器（自 Scala 3.5.0 以来）。最新的 VirtusLab Scala 调查 显示，35% 的人喜欢使用它，另外 35% 的人想要学习它。虽然不适合大型多模块项目，但 Scala-CLI 几乎为几乎所有单模块项目提供了所需的一切。它也是探索性编码小型项目和实验的出色工具。

2. 替代方案如 Mill 存在。调查发现，10%的Scala开发者喜欢使用Mill，但近50%的人希望学习它，而像Scala-CLI和Coursier这样的基础项目也是使用Mill构建的。我们认为，Mill为大型项目提供了sbt的一个很好的替代方案。Bleep虽然仍处于早期阶段，但在构建工具领域提供了一个不同的视角，同时也展现出了巨大的潜力。

3. sbt 本身也随着时间的推移有了很大的改进。在过去的几年里，我们看到了诸如 Unified Slash Syntax、sbt Project-Matrix 等改进，而即将到来的 sbt 2.0 发布将带来 构建查询、远程缓存 等其他改进。虽然仍然不是完美无缺，但到 2025 年使用 sbt 的体验已经远远优于十年前。

4. Maven 和 Gradle 也可以使用。这些构建工具在 Java 圈子里已经流行了很长时间，并且广为人知。虽然它们在开源社区中并不像 sbt 那样受欢迎，但我们看到它们被广泛应用于许多商业 Scala 代码库中。

总体而言，我们预计这个问题在将来会自行解决：一方面是通过 sbt 本身随时间不断改进，另一方面是通过项目选择提供优秀替代方案的其他工具。

生态系统易学性

我们在 Scala 语言中看到的第三大问题是生态系统的易学性。

1. Scala 生态系统始终为高级用户提供了框架：Akka、Cats-Effect、ZIO 以及其他。但它缺乏一个适合初级用户（例如：你的学生学期项目、你的新毕业生创业项目的代码库、由非工程师维护的 devops 或数据分析脚本）的平台。这些领域是 Scala 框架不适合的地方，但 Scala 语言却可以适用。

2. 在Scala生态系统中的文档传统上也一直是个问题。这加剧了上述问题：学习一个强大的框架或库已经足够困难，但糟糕的文档使得学习变得更加困难。

传统上，尽管有人可能喜欢Scala语言，但当他们尝试做一些简单的事情，比如“发起一个HTTP请求”或“启动一个服务器”时，他们会遇到一个障碍，突然需要学习关于Actor、IO单子或其他高级主题的知识，而相关文档或学习资料却不够充分。

但在这里，我们也看到了乐观的理由：

1. Scala Toolkit 和高度重叠的 com-lihaoyi 平台，它们包括许多相同的库。这些提供了几乎完整且易于使用的“新手友好”平台。它可能没有更复杂框架的所有功能和装饰，但绝对足够用于许多生产部署，并且如果需要，可以轻松过渡到更复杂的框架。

2. 最近 Scala Center 与 Rock the JVM 的合作 有望帮助改善 Scala 的教学方面。来自 Rock the JVM 的 Daniel Ciocîrlan 一直是一位杰出的教育者和高质量教育材料的创作者。我们希望这次合作能够扩大 Rock the JVM 的影响力，并帮助 Scala 新手发现并受益于他优秀的视频和课程。

这是一个我们一直在缓慢取得进步的领域，我们希望这种“新手友好”的Scala风格随着时间的推移而发展：不是以牺牲更高级框架为代价，而是在它们并行发展的同时，随着新手的数量增加，更多的人在需要时选择更复杂的框架。

如何帮助

Scala是一个社区努力的结果；没有像其他语言那样的庞大企业赞助Scala的开发。因此，我们需要社区的帮忙来推动语言的发展。这种帮助可以以各种方式实现。

财政

如果您想从财政上支持Scala，有两个主要群体您可以支持：

Scala中心

Scala中心支持以下两个方面：

1. 核心Scala语言和编译器的开发：探索、原型设计、实施、维护和调试。

2. 支持Scala社区。这包括Scala Days会议、Scala大使计划以及工具峰会。

您可以通过以下两种方式向Scala中心捐款：

• 个人捐款或让您的公司向Scala中心捐款 https://scala.epfl.ch/donate.html

• 您可以鼓励您的公司加入Scala中心咨询委员会，以持续资助它。

如果您想支持核心Scala语言和社区工作，请向Scala中心捐款。他们的大部分工作可能并不光彩夺目，但它们在确保Scala生态系统持续健康发展中发挥着关键作用。

VirtusLab

VirtusLab负责许多Scala 工具的核心开发：

• Metals和VSCode Metals插件

• Scala-CLI

• Scala 3 LTS，Scala的发布流程和一般项目管理

• Scalameta组织内的工具

如果您在使用 Metals 或 Scala-CLI 时遇到问题，并且想资助修复或改进，您应该联系 VirtusLab，邮箱地址为 scala@virtuslab.com.

代码

Scala 生态系统的大部分内容都是开源的。这意味着您可以直接深入代码，修复或改进您自己需要的部分：

• 您可以自己修复 Scala3、IntelliJ 和 Metals 中的错误。尽管代码库很大，但有人能够深入其中并修复他们自己用例所需的错误并不罕见。

• 每 three 周都会进行一次 Compiler Spree 和 Tooling Spree。这些是远程编码会议，您可以与 Scala 语言和工具的核心贡献者合作解决小规模的问题，并获取技能和知识，以应对更具挑战性的问题。

向工具和基础设施贡献修复和改进并不容易，但这也不是不可能的。Scala 工具链的大部分都是开源的，并且在过去多次由个人和公司进行了一次的快速贡献，他们只是需要修复某些问题。向这些项目提交拉取请求与任何专业软件工程师每天已经做的工作没有区别，并且可以帮助你定期改善使用 Scala 的体验。

语言设计

Scala改进流程 并不仅限于核心Scala贡献者。任何人都可以提出一个，例如 SIP-42 二进制整数字面量，SIP-61 为二进制兼容性@unroll默认参数，SIP-67 改进严格相等性。如果核心Scala团队没有优先考虑你想要的，你总是可以介入并提出自己对语言改进的建议。毕竟，没有人比你更了解自己的需求！

SIPs 进入语言并不容易。无法保证一个SIP会被接受。即使SIP成功通过，通常也需要数月甚至一年时间来完成整个审查、实施和实验过程，最终才能进入Scala的发布。相反，最初被拒绝的想法可能在经过数月或数年的额外实验和改进后找到进入的方式。但我们需要更多的贡献者提出更改，而不仅仅是限于Martin Odersky和EPFL的团队。

如果您有想法要提出，但需要帮助实施，并且有资金支付，请联系 [email protected]，我们可以帮助找到合适的专家进行合作。

结论

语言发展是一个间接的过程。核心Scala团队无法独自构建下一个重大的Scala成功故事，这也不会一蹴而就。我们能做的就是从各个方面提升Scala的体验：语言、工具和社区，并希望某处某个人会为一个新的项目选择Scala，使其成为“下一个大热门”。

我们认为Scala语言的核心吸引力在于其安全性与便利性的结合。强大的类型系统和编译器可以防止错误，提供出色的运行时性能，而简洁的语法和类型推断则使其感觉像任何脚本语言一样灵活和富有表现力。毫无疑问，其他语言也在追求相同的目标，我们认为Scala凭借其独特的混合函数式-面向对象的设计，可以在多个方面做得更好，从而吸引并留住用户。

但Scala语言及其生态系统的细节将随着时间的推移而演变，我们不应过度依赖我们已经习惯的偶然复杂性。正如Scala在2.13版本中极大地简化了集合，并且用更简单的泛型元组和其他类型系统特性取代了类型级别的体操一样，我们期望继续发现可以改进Scala的领域。始终会有关于向后兼容性、迁移和易学性的担忧，但无论如何，Scala需要不断地、批判性地审视自己，并借鉴过去二十年其他语言所学到的东西来提升开发者体验。

Scala 一直是一个社区项目，我们需要社区的帮助来推动它向前发展：无论是通过资金支持、提交拉取请求，还是在语言设计方面。我们希望社区中的每个人都能以自己的方式做出贡献，并推动语言的发展。