Evolving Scala

2025年3月24日 星期一 Martin Odersky 和 Haoyi Li 博客

关于 Scala 语言未来发展方向的讨论一直都在进行。它应该以多快的速度发展？ 需要改进什么？ 语言是否应该改变？ 本文讨论了 Scala 必须不断发展，为什么这种发展是必要的，以及我们期望这种发展采取什么方向。 我们希望这能涵盖关于 Scala 语言方向的常见问题，并帮助社区了解该语言在未来几个月和几年内的发展方向。

概要

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

Scala 有着引领编程领域潮流的历史。 为了换取比主流语言少一点的润色和稳定性，人们选择 Scala 来获得下一个十年的语言特性。 Scala 的价值始终在于这些语言特性所实现的 安全性 和 便利性 的独特结合，以及其 面向对象 和 函数式 编程思想的融合，可以优雅地适应这些特性。

但是其他语言也在不断改进，因此 Scala 必须继续创新，在增强其优势和弥补其弱点之间不断进步，尤其要注重新手的入门体验。 当然，仍然存在一些问题，尤其是在 IDE 支持和生态系统的可学习性方面，并且随着语言的发展，始终会存在关于工具、兼容性和迁移成本的担忧。 但是，如果 Scala 要在未来几年内保持其吸引力和相关性，它别无选择，只能前进。

Scala 的现状

尽管炒作已经消退，但就受欢迎程度而言，Scala 大致处于其一直以来的位置： 不完全是主流语言，但采用率远高于更小众的语言。 例如，RedMonk 语言排名在 2014 年将 Scala 排在第 14 位，在 10 年后的 2024 年仍然排在第 14 位。 在那些年中，编程格局发生了重大变化： Swift 取代了 Objective C，Go、Kotlin、Dart 和 Rust 的出现，以及 CoffeeScript 和 Perl 的衰落。 然而，在整个过程中，Scala 的地位保持不变。 尽管社区中的个人来来去去，但作为一个整体，Scala 似乎仍然拥有强大的基础和坚实的热情。

从技术上讲，Scala 的基础比 10 年前更强大。 生态系统已经成熟，各种 Reactive 或 Pure-FP 风格已经找到了它们的受众。 替代风格，例如 Scala Toolkit 和 com.lihaoyi 平台现在可用。 像 Scala-CLI 和 Mill 这样的新构建工具已经出现，并且像 Scalafmt 和 Scalafix 这样的开发者工具已经得到广泛使用。 IDE 仍然是一个痛点，但我们希望它们在 2025 年的过程中得到改善。 值得庆幸的是，大量使用符号运算符已经过时。

Scala 一直是一种前沿语言，证明了诸如 lambdas、records 和 pattern matching 之类的语言特性的可行性，这些特性在 10-15 年后被 Java、Python 和其他主流语言采用。 目前尚不清楚主流语言将在未来 10-15 年内采用哪些当前的 Scala 特性。

Scala 将走向何方？

在本节中，我们将讨论核心 Scala 开发者将重点关注的一些领域。

安全性和便利性：二者择一？

Scala 一直是一种混合语言。 人们经常谈论面向对象和函数式风格的融合。 但它的另一种融合是 安全性 和 便利性。 传统上，像 Python 这样的“脚本”语言是不安全的但很方便，而像 Java 这样的“应用程序”语言是安全的但不方便。 Scala 是第一个证明你可以在同一种语言中同时做到这两点的语言。 像 Swift 或 Kotlin 这样更现代的语言也朝着这个方向发展，当 Scala 刚开始时，这个想法是闻所未闻的。

但是，在过去的二十年中，编程格局并没有停滞不前。 曾经是 Scala 独有的许多东西现在已经很普遍了。 所有现代语言都提供泛型、类型推断、lambdas、records、pattern matching 和其他此类特性。 为了继续吸引用户，Scala 必须继续在两个方向上创新：

1. 提高安全性 而不损害便利性： 诸如 capture checking、explicit nulls、safe initialization、multiversal equality 等特性。
2. 提高便利性 而不损害安全性： 诸如 enums、optional braces、named tuples 等特性。 关于 aggregate data literals 的讨论引起了很多兴趣，尽管现在预测结果还为时过早。

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

其他语言也在追求这些目标，但我们相信 Scala 比大多数语言做得更好： 它的类型系统、pattern matching、集合库、多重继承系统等都是一流的，即使其他语言也有自己的产品。 因此，有可能简单地执行和组合特性，并且比其他语言做得更好，其设计以干净和有原则的方式统一了这些特性，而不是临时拼凑它们。

展望未来，Scala 必须继续追求安全性和便利性的双重目标。 明天流行的框架可能与今天的框架不同，而今天的框架又与过去几年的框架不同。 但是，在过去的几十年里，开发者一直想要安全性和便利性，我们预计在未来几年内它将继续有需求。

消除粗糙的边缘

Scala 不再是一种新语言。 很多事情在 20 年前看起来像是好主意，但并非所有这些决定都奏效了。 尽管长期的 Scala 开发者可能已经习惯了这些特殊性，但 Scala 语言需要不断地消除这些粗糙的边缘：

1. 某些特性，如 scala-actors、scala-parser-combinators 或 scala-xml，此后已被移除。 它们现在位于单独的库中，你可以根据需要使用或不使用它们，但它们不再是语言或标准库的核心部分。 其他此类清理包括 Scala 2.13 集合大修。
2. 随着我们的深入，更多的问题正在得到处理： @unroll 用于避免默认参数和 case classes 的二进制兼容性问题，目前处于实验阶段 (SIP-61)，并且 for-comprehension 改进正在预览中 (SIP-62)， 应该有助于解决这些 Scala 语言特性在使用过程中长期存在的问题。
3. 还有一些长期存在的问题尚未解决，但正在讨论中： flexible varargs、unpack、其他缺点 涉及 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 的高级用户一直在提交他们自己的补丁和改进 —— scala.concurrent.Future 来自 Akka 世界，partial unification、generic tuples 和 kind-projector 来自 pure-FP 世界 —— 我们希望他们将继续这样做。 相比之下，新手必须依靠核心 Scala 维护者来确保他们获得良好的体验。

实际上，这意味着：

1. 优先为更简单、更容易的库（例如 Scala Toolkit 和 com.lihaoyi 平台）提供代码和文档支持。
2. 在不必要的情况下，将 Scala 语法与其他语言对齐。 通过 import foo.* 进行 Wildcard imports 和 通过 foo* 进行 vararg splices 已经落地（后者取代了旧的 snail operator foo@_*)。

下一个大型 Scala 项目很可能由新手拿起该语言来解决以前没有人想到要解决的问题而开始。 他们会很聪明，但他们不会是推动 Scala 语言极限的专家，他们也不会使用最复杂的语言特性或设计模式。 他们会懂 Java 或 Python 或 JavaScript，因为那是他们在学校里学到的东西。 我们需要确保这些人可以轻松入门 Scala 语言。

考虑的替代方案

关于 Scala 应该走向何方，总是存在不同的意见。 我们将讨论围绕语言方向经常出现的两个想法。

为什么不全力投入 Framework X？

社区的一个常见要求是“全力投入” Scala 社区中的某个框架或工具链。 例如：

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

这些想法值得讨论。 毕竟，使用 IO monads 将其用于纯函数式编程的 Scala 子社区一直健康而充满活力。 但是，在更深入的分析之后，这种方法存在一些问题：

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 上具有 lambdas 和 pattern matching 的语言。
• Akka 选择了 Scala，因为它是一种简洁、高性能的语言，支持使用 Futures 或 Actors 实现轻量级并发。
• Scalaz 和 Cats 选择 Scala 作为一种具有丰富类型系统的简洁语言。

其他语言采用这些特性给 Scala 带来了创新压力。 在 2025 年，基本上 RedMonk 前 20 名 中的每种语言都具有 lambdas、pattern matching、轻量级并发和类型系统！ 那么，为什么任何项目都会选择 Scala 呢？

Scala 无法仅凭稳定性和润色与主流语言竞争，因此如果我们今天停止特性开发，Scala 最终将成为一种特性更差、润色和稳定性更差且没有存在理由的语言。 因此，Scala 需要稳定的改进流来维持它，为人们和项目提供选择该语言的理由。 我们可能会犯错 —— 没有通往成功的有保证的道路 —— 但特性冻结是一条通往停滞和失败的有保证的道路。

Scala 生态系统中的未解决问题

Scala 生态系统并非没有问题。 在这里，我们将简要介绍我们认为 Scala 今天面临的最大挑战，以及我们已经或将要做些什么来解决这些挑战。

工具：IDE

在最新的 VirtusLab Scala Survey 中，“工具”是被强调为需要改进的最大领域。 这主要意味着 IDE（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 Center 顾问委员会的成员。 这已经改善了 JetBrains 和 Scala 编译器团队之间的沟通和协调，并有助于避免过去出现的问题，即 IntelliJ 需要时间来赶上 Scala 的更改。
3. 最近的语言更改已经相对迅速地进入 IntelliJ： SIP-64 Improved Given Syntax 和 SIP-58 Named Tuples 自 IntelliJ 2024.3 以来已经可以使用，而 SIP-62 For Comprehension Improvements 将在 2025.1 中提供。

我们承认还有工作要做。 IntelliJ 团队正在努力为 Scala 3 带来最佳支持，你可以期待在未来几个月内会有更多改进。

Metals - Scala 语言服务器

Metals 最常与 VSCode 一起使用，但也支持其他编辑器。 Metals 面临着与 IntelliJ 不同的挑战： 它一直使用实际的 Scala 编译器来进行其代码智能，因此它始终与实际语言同步。 但是它在稳定性方面存在问题（例如，[#6478](https://www.scala-lang.org/blog/2025/03/24/https:/github.com/scalameta/metals/issues/6478）），其中一些问题源于其多进程架构的复杂性，另一些问题源于其与 Scala 3 的较新集成（例如，[#6628](https://www.scala-lang.org/blog/2025/03/24/https:/github.com/scalameta/metals/issues/6628））。 Metals 维护者目前专注于解决最突出的问题，但是如果你知道你的代码库中存在任何问题，请在 https://github.com/scalameta/metals/issues 上打开一个 issue，VirtusLab 的团队很乐意查看（如有必要，甚至签署 NDA）。

Scala 3 编译器开发人员已经大量使用 IntelliJ 和 Metals，并且我们知道开发者在使用这两个 IDE 时面临的问题。 我们将继续报告发现的问题，并将与 IntelliJ 和 Metals 的维护者合作，以改善编译器和 IDE 之间的集成。 但是，我们也需要社区中的人们积极参与报告问题，以便 IDE 维护者可以调查和修复它们。

构建工具

在过去的十年或更长时间里，构建工具 sbt 的复杂性一直是 Scala 社区中长期存在的问题。 但是，我们认为隧道尽头有曙光：

1. Scala-CLI 变得流行起来。 它现在是默认的 Scala 启动器（自 Scala 3.5.0 以来）。 最近的 VirtusLab Scala Survey 显示，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 版本带来了 build queries、remote caching 和其他改进。 虽然仍然不完美，但在 2025 年使用 sbt 的体验与十年前的体验相比有了很大的改善。
4. 也可以使用 Maven 和 Gradle。 这些构建工具长期以来在 Java 商店中很受欢迎并且很熟悉。 虽然在开源社区中不太受欢迎，但我们看到它们在许多商业 Scala 代码库中使用。

总的来说，我们预计这个问题将在未来自行解决： sbt 本身会随着时间的推移而改进，并且项目会选择其他提供出色替代方案的工具。

生态系统的可学习性

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

1. Scala 生态系统一直有针对复杂用户的框架： Akka、Cats-Effect、ZIO 等。 但是它缺乏一个针对不太复杂用户的平台： 例如，你的学生学期项目、你的新毕业生创业公司代码库、你的由非工程师维护的 devops 或数据分析脚本。 这些领域是 Scala 框架 一直不太适合的领域，但 Scala 语言 可以胜任。
2. Scala 生态系统中的文档传统上也是一个问题。 这加剧了上述问题： 学习一个强大的框架或库已经足够困难了，但是如果文档很差，学习会变得比它需要做的更困难。

传统上，尽管有人可能喜欢 Scala 语言，但当他们开始做一些简单的事情（例如“发出 HTTP 请求”或“启动服务器”）时，他们会遇到一道墙，他们突然需要学习 Actors、IO monads 或其他高级主题，并且没有足够的文档或学习材料。

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

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 Center

Scala Center 支持两件事：

1. 核心 Scala 语言和编译器的开发： 探索、原型设计、实施、维护和调试。
2. 支持 Scala 社区。 这包括 Scala Days 会议、Scala 大使计划和工具峰会。

你可以通过两种方式向 Scala Center 捐款：

• 个人捐款或让你的公司向 Scala Center 捐款 https://scala.epfl.ch/donate.html
• 你可以鼓励你的公司加入 Scala Center 顾问委员会，以便持续资助它。

如果你想支持核心 Scala 语言和社区工作，请捐款给 Scala Center。 他们的许多工作并不光鲜亮丽，但它在帮助确保 Scala 生态系统的持续健康方面发挥着关键作用。

VirtusLab

VirtusLab 对许多 Scala 工具 进行核心开发：

• Metals 和 VSCode Metals 插件
• Scala-CLI
• Scala 3 LTS，发布过程和 Scala 的一般项目管理
• Scalameta 组织内的工具

如果你在使用 Metals 或 Scala-CLI 时遇到问题，并且想帮助资助修复或改进，你应该通过 scala@virtuslab.com 联系 VirtusLab。

代码

Scala 生态系统的大部分是开源的。 这意味着你可以直接深入研究代码并进行你自己想要的修复或改进：

• 你可以自己修复 Scala3、IntelliJ 和 Metals 中的错误。 尽管代码库很大，但有人深入研究并为自己的用例进行必要的修复的情况并不少见
• 每三周运行一次 Compiler Spree 和 Tooling Spree。 这些是远程编码会话，你可以在其中与核心 Scala 语言和工具贡献者协作处理小规模错误，并获得解决更雄心勃勃的问题的技能和知识。

为工具和基础设施贡献修复和改进并不容易，但也不是不可能的。 Scala 工具链的大部分是开源的，并且过去多次收到个人和公司的临时贡献，他们只需要修复一些东西。 向这些项目提交 pull request 与任何专业软件工程师每天已经