进化中的 SCALA 语言

158 条评论 | |

关于 Scala 语言未来发展方向的讨论一直没有停止过。它应该发展多快？哪些方面需要改进？语言是否应该改变？本文将讨论 Scala 必须如何持续演进、为什么必须演进以及我们期望的演进方向。我们希望这篇文章能够涵盖许多有关 Scala 语言发展方向的常见问题，并帮助社区了解 Scala 语言在未来数月或数年内的发展方向。

摘要

虽然 Scala 已不再像 2010 年代中期那样风头正劲，但根据大多数调查，Scala 仍处于主流语言之外。从技术角度来看，Scala 的核心语言和生态系统在过去十年中得到了极大的改进。在很多方面，Scala 如今的基础都比 10 年前要好得多。

Scala 一直引领着编程领域其他语言的发展。与主流语言相比，Scala 的完善性和稳定性稍逊一筹，但人们选择了 Scala，从而获得了下一个十年的语言特性。Scala 的价值始终在于这些语言特性所带来的安全性和便利性的独特结合，以及它融合了面向对象和函数式编程思想，能够优雅地容纳这些特性。

但其他语言也在不断改进，因此 Scala 必须继续创新，同时改进自身的优势和劣势，尤其要关注新用户的入门体验。当然，还有一些持续存在的问题，尤其是 IDE 支持和生态系统的可学习性，而且随着语言的发展，工具、兼容性和迁移成本等问题也会一直存在。但是，Scala 要想在未来几年保持吸引力和相关性，就别无选择，只能向前迈进。

Scala 今天的地位

虽然炒作已经平息，但从流行度来看，Scala 的地位始终未变：虽然还不是主流语言，但其采用率远高于小众语言。例如，RedMonk 语言排行榜在 2014 年将 Scala 排在第 14 位，10 年后的 2024 年，Scala 仍然排在第 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 等开发者工具也得到了广泛应用。集成开发环境仍然是一个痛点，但我们希望它们在 2025 年会有所改善。值得庆幸的是，符号运算符的大量使用已经过时。

Scala 一直是处于领先地位的语言，它证明了诸如 lambdas、记录和模式匹配等语言特性的可行性，这些特性在 10-15 年后被 Java、Python 和其他主流语言所采用。10-15 年后，主流语言将采用哪些当前的 Scala 特性，我们拭目以待。

Scala 将何去何从？

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

安全性和便利性：选两个

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

然而，在过去的二十年里，编程领域并没有停滞不前。Scala 过去所独有的很多东西现在都很常见。所有现代语言都提供了泛型、类型推断、lambdas、记录、模式匹配等功能。为了继续吸引用户，Scala 必须在这两个方向上不断创新：

  1. 在不影响方便性的前提下提高安全性：捕获检查、显式 null、安全初始化、多重相等等特性。
  2. 在不影响安全性的前提下提高便利性：枚举、可选括号、命名元组等特性。关于聚合数据字面的讨论引起了很多人的兴趣，不过要知道讨论的结果还为时尚早。

Scala 生态系统广泛而多样，但我们认为这两个目标是共同的主线。无论您是在 JVM 上使用 Akka actors 构建后端服务，还是通过 Scala.js 在浏览器中构建网络用户界面，抑或是通过 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. 其他一些长期存在的问题尚未得到解决，但正在讨论中：灵活的 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.* 进行的通配符导入和通过 foo* 进行的 vararg 拼接已经实现（后者取代了旧的蜗牛运算符 foo@_*）。

下一个大型 Scala 项目很可能是由新手发起的，他们学习 Scala 语言是为了解决一个前人从未想过的问题。他们会很聪明，但不会是挑战 Scala 语言极限的专家，也不会使用最复杂的语言特性或设计模式。他们知道 Java、Python 或 JavaScript，因为那是他们在学校学到的东西。我们需要确保这些人能够轻松上手 Scala 语言。

经过深思熟虑的替代方案

关于 Scala 的发展方向，总是众说纷纭。我们将讨论围绕语言发展方向反复出现的两种观点。

为什么不完全采用框架 X？

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

  1. 将 Scala 作为纯函数式编程语言
  2. 将 IO monads 作为结构化应用程序的方法

这些想法都值得讨论；毕竟，使用 Scala 进行纯函数式编程和 IO monads 的 Scala 子社区一直都很健康、充满活力。不过，如果深入分析，这种方法也存在一些问题：

  1. 从设计上讲，Scala 是一种灵活而富有表现力的语言。历史证明，这有利于创新：十年前，Akka 和 Scalaz 是流行的框架。Scalaz 后来让位于 ZIO、Cats-Effect、Monix 和 FS2 等较新的函数库。Kyo 似乎很有前途，但还很年轻。Scala 语言必须具有足够的通用性，以支持这种自然演进，而不能屈从于逐年兴衰的特定框架。
  2. Scala 的核心开发人员并不是框架专家。在 Akka 流行时，他们并不是演员模型方面的专家，如今他们也不是 IO monads 方面的专家。

因此，我们需要这些子社区中的高级用户为自己代言，推动社区所需的语言改进。
因此，Scala 必须通过构建任何框架或库都能受益的功能来保持通用性。我们鼓励框架爱好者对 Scala 语言提出改进建议：虽然不是每个具体想法都会被采纳，但反馈意见会推动语言的变化，使所有框架受益。

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

另一个常见的要求是 “停止实现功能”。在语言讨论中，经常会有对工具支持、就业市场或其他方面不满意的人提出这样的要求。这些情绪是可以理解的。但实际上，冻结功能开发会让 Scala 语言走向灭亡。

与 Java 等语言相比，Scala 的功能一直比较丰富，但打磨和稳定性较差。Scala 的核心价值主张是，作为交换，你可以获得未来的语言特性，而这些特性是其他语言所不具备的，而且只能在 10-15 年后才能获得：

  • Apache Spark 在 2014 年选择了 Scala，将其作为一种在 JVM 上使用 lambdas 和模式匹配的语言。
  • Akka 选用 Scala 是因为它是一种简洁、高性能的语言，支持 Futures 或 Actors 的轻量级并发。
  • Scalaz 和 Cats 选择 Scala 是因为它是一种具有丰富类型系统的简洁语言。

其他语言纷纷采用这些特性，给 Scala 带来了创新的压力。2025 年，RedMonk 排名前 20 的语言基本上都有 lambdas、模式匹配、轻量级并发和类型系统！那么，为什么会有项目选择 Scala 呢？

Scala无法仅凭稳定性和完善性与主流语言竞争，因此如果我们今天就停止功能开发，Scala最终将成为一种功能更差、完善性和稳定性更差、没有存在理由的语言。因此，Scala 需要源源不断的改进来维持，让人们和项目有理由选择这种语言。我们可能会出错–没有通往成功的必经之路，但功能冻结则是通往停滞和失败的必经之路。

Scala 生态系统中的公开问题

Scala 生态系统并非没有问题。下面我们将简要介绍我们认为 Scala 目前面临的最大挑战，以及我们已经或将要采取的应对措施。

工具： IDE

在上一次 VirtusLab Scala 调查中，“工具 ”是需要改进的最大领域。这主要是指集成开发环境（IntelliJ 和 VSCode）和构建工具（如 sbt），这也是每个编写 Scala 的人都必须使用的工具。

Scala 社区使用的两个主要集成开发环境是 IntelliJ 和 VSCode。在上述调查中，约 80% 的受访者使用 IntelliJ，约 50% 的受访者使用 VSCode，还有一些受访者同时使用这两种工具。

INTELLIJ

IntelliJ对Scala 3的支持质量与传统上对Scala 2的支持质量相比仍有差距。尽管如此，IntelliJ 仍在稳步前进，而且最近的改进速度也在加快。

  1. Scala 3 最近引入了 “预览 ”功能的概念：这些功能已经从实验阶段稳定下来，但尚未获得集成开发环境和生态系统其他部分的支持。这样做的目的是为了给 IntelliJ 和其他集成开发环境留出时间，使其在语言发展过程中不至于落后。
  2. JetBrains 现在是 Scala 中心顾问委员会的成员。这已经改善了 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），其中一些问题源于其多进程架构的复杂性，另一些则源于与 Scala 3 的较新集成（如 #6628）。Metals 维护者目前正集中精力修复最突出的问题，但如果您发现代码库中存在任何问题，请在 https://github.com/scalameta/metals/issues 开启一个问题，VirtusLab 团队会很乐意查看（必要时甚至会签署保密协议）。

Scala 3 编译器的开发者已经大量使用 IntelliJ 和 Metals，我们也了解开发者在使用这两个集成开发环境时所面临的问题。我们将继续报告发现的问题，并与 IntelliJ 和 Metals 的维护者合作，改进编译器和 IDE 之间的集成。但我们也需要社区成员积极报告问题，以便集成开发环境的维护者能够调查并修复这些问题。

构建工具

过去十多年来，构建工具 sbt 的复杂性一直是 Scala 社区的老大难问题。不过，我们认为隧道尽头已经出现了曙光：

  1. Scala-CLI 已经开始流行。它现在是默认的 Scala 启动器（自 Scala 3.5.0 起）。在上一次 VirtusLab Scala 调查中，35% 的人喜欢使用 Scala，35% 的人想学习 Scala。虽然 Scala-CLI 不适合大型多模块项目，但它几乎可以满足所有单模块项目的需要。它还是小型项目和实验的探索性编码工具。
  2. 还有 Mill 等替代工具。调查发现，10% 的 Scala 开发人员喜欢使用 Mill，但也有近 50% 的人想学习它，Scala-CLI 和 Coursier 等基础项目就是使用 Mill 构建的。我们认为，Mill 为大型项目提供了除 sbt 之外的最佳选择。Bleep 虽然还很年轻，但它在构建工具领域提供了一种与众不同的方式，也展现出了广阔的前景。
  3. sbt 本身随着时间的推移已经有了很大的改进。过去几年中，sbt 的改进包括统一斜线语法（Unified Slash Syntax）、sbt 项目矩阵（sbt Project-Matrix），即将发布的 sbt 2.0 版本还将带来构建查询、远程缓存和其他改进。虽然仍不完美，但与十年前相比，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 中心与 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 中的错误。虽然代码库很大，但也不是没有人可以深入其中，针对自己的用例进行必要的修正
  • 每三周会举办一次编译器竞赛和工具竞赛。在这些远程编码会议上，您可以与 Scala 语言和工具的核心贡献者合作，解决一些小问题，并掌握解决更大问题的技能和知识。

为工具和基础架构提供修正和改进并不容易，但也并非不可能。Scala 工具链的大部分内容都是开源的，过去曾多次收到个人和企业的临时贡献，他们只需要修复一些问题。向这些项目提交拉取请求与任何专业软件工程师每天所做的工作并无不同，而且还能帮助您改善自己经常使用 Scala 的体验。

语言设计

Scala 改进过程并不局限于 Scala 的核心贡献者。任何人都可以提出改进建议，例如 SIP-42 二进制整数字面、SIP-61 @unroll 默认参数以实现二进制兼容性、SIP-67 改进严格相等。如果 Scala 核心团队没有优先考虑您的需求，您也可以自己提出改进建议。毕竟，你比任何人都更了解自己的需求！

要在语言中加入 SIP 并不容易。我们无法保证 SIP 会被接受。即使是通过审核的 SIP，通常也需要几个月甚至一年的时间来经历审核、实现和实验的全过程，最终才能发布到 Scala 中。相反，即使是最初被否决的想法，也可能在经过数月或数年的额外实验和完善之后，才被采纳。但是我们需要更多的贡献者来提出修改意见，而不仅仅局限于 Martin Odersky 和 EPFL 的同事。

如果您有想法要提出，但需要帮助实现，并且有资金支付，请联系 scala.center@epfl.ch，我们可以帮助找到专业人员签订合同。

结论

语言开发是一个间接的过程。Scala 核心团队不可能自己开发出下一个 Scala 成功案例，也不会在一夜之间实现。我们能做的是在语言、工具和社区等各个方面改善 Scala 体验，并希望在某个地方有人会选择 Scala 来开发新项目，从而成为 “下一件大事”。

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

但是，Scala 语言和生态系统的细节会随着时间的推移而不断发展，我们不应该过分执着于我们已经习以为常的附带复杂性。正如 Scala 集合在 2.13 中被大大简化，类型级别的繁琐工作在 Scala 3 中被更简单的泛型元组和其他类型系统特性所取代一样，我们希望继续找到可以进行修改的地方，以改进 Scala。在向后兼容性、迁移和可教性方面总会有一些问题，但无论如何，Scala 都需要不断以批判的眼光审视自己，并借鉴其他语言在过去二十年中的经验，以改善开发者的体验。

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

本文文字及图片出自 evolving scala

你也许感兴趣的：

共有 158 条讨论

  1. > 另一个常见的要求是 “停止实现功能”。

    是的，几乎所有 Scala 3 开发人员都有这样的要求。停止。至少在几年内。

    工具和社区跟不上脚步，而且语言已经很好了，重点应该放在生态系统而不是语言上。

    但 Scala 开发人员根本听不进去，而这正是编程语言作为一个持续研究项目的结果，许多学生和教授都依赖于这个项目。

    说 “如果我们停止开发新功能，语言就会消亡 “是不够的，因为没有证据证明这一点，而且社区中的大多数人都对坚持不懈的开发感到厌倦。

    回复

    1. 在我看来，工具是导致该语言在开发者心目中的地位一落千丈的主要原因之一。

      如果我们想说选择什么语言并不重要，因为无论如何都能找到任何解决方案，那么与该语言相关的工具能为我们带来什么就绝对重要了。

      回复

      1. 关于 “工具”，我们必须说得更具体一些–你错过了什么

        回复

    2. 这是对情况的根本误读。

      语言极客需要的是语言极客，而 Scala 用户需要的是 “更快的马”。(更快的编译器、更好的项目/包管理器[抱歉 sbt]、增量编译器、兼容 LSP 的编译器等等。这些都是很好很好的东西，也是完全正确和重要的东西！）。

      不幸的是，通常企业支持者能提供这些东西，而不是语言研究者。

      工具和社区没有必要跟上。如果 Scala 2.12 对社区如此有利，那就继续使用它吧。

      显而易见的问题是，Scala 3 提供的功能（无论 Odersky 等人开发的是什么，都可能对很多 Scala 用户有用）会刺激注意力分散。

      是的，社区确实跟不上。(然而，社区并不是一盘散沙，多年来它能够产生如此多的效果库，我都数不清了）。

      但把这个责任推给研究人员是一个不可饶恕的错误。

      回复

      1. 这是一个公平的描述。不幸的是，Scala 的企业支持比 Java 这样的东西要薄弱得多。:(

        回复

        1. 也许是这样，友好地告诉他们这一点也没什么，但在我看来，社区有时对研究人员非常辱骂。(嗯，还有……总的来说，这些年来 Scala 戏剧性的事件不是没有发生过，强大的语言往往会以其强大的愿景吸引人们。当然，研究人员的人际交往能力也时常有待提高）。

          总之，从石头里榨水可能比说服某些人更容易：）。

          回复

    3. 不幸的是，Rust 也犯了完全相同的错误。

      编辑：它过于关注语言而非生态系统。

      回复

      1. 1. Rust 从一开始就拥有好十倍的工具。Cargo vs SBT，这可不是闹着玩的。

        2. 在过去 5 年中，Rust 的编译器性能提高了 3 倍。

        3. 在过去 6 年中，Rust 没有获得任何重要的新语言特性。大多数语言改进都是在提高现有功能的正交性。

        4. Rust 从一开始就具有出色的向后兼容性。2015 年编写的代码/库仍然可以与 2025 年的代码一起编译和使用。

        5. Rust 得到了所有主要集成开发环境/编辑器提供商的大力支持。

        6. Rust 很容易与其他语言和生态系统集成。从 Python 调用 Rust 比从 Python 调用 Scala 更容易。从 Rust 中调用 C 语言比从 Scala 中调用 C 语言更容易，性能也更高。诸如此类。可悲的是，Scala 甚至在与 Java 的互操作性上也很吃力；理论上这应该是很容易的，因为它们是同一个平台。

        说真的，在我看来这不像是同样的错误。实际上恰恰相反。

        回复

        1. >过去 6 年里，Rust 没有获得任何重要的新语言特性。大多数语言改进都是在提高现有功能的正交性。

          Rust 还配备了一个正常运行的纪元/版本系统，这使得在不失去向后兼容性的情况下，重新修改现有语言特性以提高通用性、优雅性等是可行的。我不确定 Scala 是否有类似功能。

          此外，Rust 的 nightly/stable 分离意味着大多数新特性都不会进入最终采用阶段，除非在设计上达成了真正的共识。在新特性真正稳定之前，我们会尽一切可能去掉附带的复杂性。

          大多数语言实现如果 “在过去 6 年中没有获得任何重要的新语言特性”，就会被描述为大致停滞或陈旧，但 rust 却截然不同。

          回复

        2. 在我几乎 100% 的项目中，我都需要以这样或那样的方式对某些东西进行散列。标准库中的 SHA-256 在哪里？

          回复

          1. C 或 C++ 标准库中也没有 sha-256。像 sha-256 这样的加密哈希算法并不一定要放在标准库中。

            Python 标准库中有很多几乎没人使用的旧模块。但删除它们会破坏向后兼容性的保证。Rust 项目已经决定要保持标准库的精简。这在实践中效果很好，因为 cargo 是一个非常出色的软件包管理器。

            回复

          2. Rust 标准库是最小化的（至少与 Java/.NET 相比），因此没有 SHA-266。

            如果你想要一个更有用的标准库，或许可以考虑 Go。

            回复

            1. Rust 标准库是极简的，因为它必须支持多种平台，而且必须是轻量级的，易于移植。它还必须长期稳定。一旦某些东西进入了标准库，就很难再删除/修改/重新设计了。Java 有多少半成品的日期时间实现？

              不过，使用第三方库轻而易举，这也弥补了标准库的简约性。

              回复

      2. 请详细说明您认为哪些改动是错误的？

        ———

        在我看来，目标是明智的旗舰目标（以 2025H1 为例 [1]）都是关于 DX 的，并关注下游开发人员及其需求（全员参与，内核中的 Rust）。

        通常的 “编译时间 “问题[2]（通常是链接时间和 LLVM 吞吐量等）都是正在努力解决的问题，但从根本上说，它们都只能通过缓存、增量编译和更好的开发者工具来解决，而这些都不是语言问题。

        [1] https://rust-lang.github.io/rust-project-goals/2025h1/goals….

        [2] https://old.reddit.com/r/rust/comments/1if5wpm/high_hopes_fo…

        回复

      3. > 编辑：它过于关注语言而非生态系统。

        您这是什么意思？缺少了什么？

        回复

          1. 然而，是 Go 最近增加了大的语言特性（泛型、迭代器、改变 for 循环的语义），而不是 Rust。自从 7 年前添加了 async 之后，Rust 就再也没有添加过任何新的重要特性。Rust 语言比 Go 语言要稳定得多，部分原因是 Rust 在 1.0 版本中就有了更多特性，而 Go 只能逐步添加（下一个是什么？） 它还拥有更先进的机制，既能发展语言，又不会破坏现有代码（版本）。这些都是 Go 和 Scala 还没有解决的问题。

            回复

          2. Go 已经证明，人们需要廉价的线程。如果没有廉价线程，它将一事无成。

            现在连 Java 都有了廉价线程（Loom）。

            Go 甚至还有泛型。只是比 Java 晚了 20 多年而已。而且，现在 Java 拥有的更多特性很可能会渗透到 Go 中。如果 Go 想要生存下去的话。

            说了这么多，我想说的是，市场上已经没有空间再容纳另一种愚蠢而简单的 Algol 语言了。Go 已经占据了这个市场。如果 Go 不想被挤出市场，就必须增加开发者想要/需要的功能。

            不仅 Scala 必须进化。

            回复

            1. Go 已经证明，尽管开源为当今大多数大型科技公司提供了动力，但我们仍然需要大公司的支持才能在科技界取得成功

              Java 需要苹果，Go 需要谷歌，React 需要 Facebook，TypeScript 需要微软，等等

              从这个角度来看，Rust 其实是一个相当独特的成功故事，因为没有一家单一的大型科技公司在推动它

              回复

            2. >现在，即使是 Java

              ，Java 也是除了 Erlang、Haskell 和 Go 之外为数不多的语言之一。这个 “甚至 “绝对没有道理。

              回复

            3. > 现在连 Java 都有廉价线程了

              如果你说的 “廉价线程 “是指 M:N 线程，也就是纤维/绿色线程，那么 Java 早在 Go 之前的 Solaris 上就有了。

              回复

              1. 这与当前的虚拟线程完全不是一回事，后者会自动将（多种）阻塞 IO 转为非阻塞。

                回复

                1. 如果 “自动 “是指 “Golang 的做法”，那么这就是 M:N 线程/光纤的意义所在。

                  回复

                  1. 我的观点是绿色线程与虚拟线程完全不同。

                    回复

      4. Rust 比 Scala 年轻。888/3/redcannon218

        但 Go 已经证明，生态系统比语言更重要。

        是时候改变优先级了。

        回复

    4. > > 另一个常见的要求是 “停止实现功能”。

      > 是的，这是几乎所有 Scala 3 开发人员的共同要求。停止。至少在几年内。

      我认为 Capture Catching 来得太快了。它能让我们编写更简单的程序，比现代 Java & co 更有优势。

      不要在生产代码中使用试验性 Scala 功能。它们可能会改变或被移除。而且 IDE 很可能不支持这些功能。但这是常识。

      回复

      1. – 更快的编译时间

        – 更快的编译时间

        – 更快的编译时间

        – 我希望 sbt+scalatest（被祝福的构建工具/测试框架）不要不断泄露内存（https://olegych.github.io/blog/sbt-fork.html，这是我特别遇到的一个问题）

        – 当我在构建中按住 ctrlclick 键进入 settingKeys 时，我希望能得到有用的文档。sbt

        – 我希望 Intellij 在使用上下文边界和 implicits 的函数显式传递所需的隐式参数时不会出错

        – 我希望 intellij 始终与 scala 编译器保持一致

        回复

    6. >是的，几乎所有 Scala 3 开发人员都有一个非常常见的问题。别说了。至少在几年内。

      请避免以偏概全。不是 “所有”。

      回复

      1. 知道这是泛化，你也应该知道泛化不是字面解读。

        回复

  2. Scala 对我和我工作过的团队来说都是非常愉快和富有成效的。v2 -> v3 过渡的头几年有点艰难，因为工具和生态系统都在跟上，但现在我们很高兴地使用 Scala 3，没有回头路可走。语言和生态系统正朝着好的方向发展，我很高兴能通过我的 Scala.js 开源库在其中发挥一点作用（这也是我一开始接触 Scala 的全部原因–比 Typescript 简单安全得多）。

    Scala也许不会在所有老牌企业中取代Java，但以我个人在初创公司工作的经验来看，它对于那些需要高效地编写安全、符合人体工程学的代码的小型团队来说，是一个非常好的倍增器。金融、医疗系统等。同时，它也符合人体工程学，让我在非关键任务的个人项目中也乐于使用。

    回复

    1. >对于那些需要高效地编写安全、符合人体工程学的代码的小型团队来说，它是一个了不起的倍增器。

      这其中有多少是由于语言的实际特性，又有多少是由于有才华、有抱负的软件开发人员将函数式编程语言作为满足其智力需求的一种手段而产生的选择偏差？

      回复

      1. 我曾在一家大量使用函数式编程库的初创公司工作过，也曾在一家使用你能想象到的最简单的 Scala 的初创公司工作过（没有看到 cats / zios / kyos 等等），这两家公司都从 Scala 语言本身受益匪浅。丰富、安全和健全的类型系统，加上符合人体工程学的语法和经过深思熟虑的功能，使得阅读和编写代码都变得非常容易，最重要的是，可以非常自信地进行大规模修改，这在快速发展的初创公司中是绝对必要的，因为在这种公司中，业务需求一直在不断变化，功能在紧急发布时会产生一些技术债务，需要在日后有效解决，等等。

        就人才而言，与任何非默认技术栈一样，肯定会有一些自我选择。Scala 是一款锋利的工具，既有人因为其锋利的实用性而被它吸引，也有人因为想玩锋利的东西而被它吸引。这两类人都很聪明，但后一类人在过去给 Scala 带来了不好的名声，因为他们太聪明了，因此写出的代码太聪明，别人无法理解。但如今人才库中的总体氛围更加务实。

        回复

        1. >我曾在一家大量使用函数式编程库的初创公司工作过，也曾在一家使用你能想象到的最简单的 Scala（没有看到 cats / zios / kyos 等）的初创公司工作过，这两家公司都从 Scala 语言本身受益匪浅。

          如今，你难道不想在后者中使用 Kotlin 吗？它似乎比任何 “普通 “的 Scala 种类都拥有更广泛的应用。

          回复

          1. 我不知道，Kotlin 有它的优点，而且由于 Android 的存在，它绝对会继续存在下去，但我总觉得它或多或少只是 Java 8 的语法糖而已，以至于现在连 Java 都有了一些更高级/优雅的特性，比如代数数据类型的适当模式匹配，而 Kotlin 却只能用 instanceof 检查这种愚蠢的糖。

            Scala 总是要优雅得多，而且实际上走得更远。

            回复

          2. Kotlin的采用率并不比Scala高多少，对我来说也没什么好处，因为它主要集中在Android领域，而Android与我无关。此外，这还意味着 Kotlin.js 本身和生态系统都不如 Scala.js–而 Scala.js 的质量正是我使用 Scala 的一半原因。

            在 Haskell <—> Scala <—> Java 的光谱上，Kotlin 作为一种语言也更接近 Java。我们只是不想在这个频谱上向任何一个方向发展，Scala 完全符合我们的想法。

            有趣的是，这里有些人说 Java 最近的改进会蚕食 Scala 的市场，而实际上，它似乎会首先蚕食 Kotlin。

            回复

        2. 你能举个例子，说明你的选择让大规模变革变得更容易了吗？

          回复

      2. 我在 Scala 代码库中度过了一段（相对）糟糕的时光。我参与的上一个代码库从修改代码到运行或测试需要等待 6 分钟。但我还是想和 Scala 开发人员一起工作。

        我宁愿在 Java 代码库上与 Scala 开发人员一起工作，也不愿在 Scala 代码库上与 Java 开发人员一起工作。

        这与智力无关。而是不要在每一个新的工作场所都重复同样的废话。尽可能避免可变性和空值等。

        回复

        1. >我宁愿在 Java 代码库上与 Scala 开发人员共事，也不愿在 Scala 代码库上与 Java 开发人员共事。

          一旦项目进入 BAU/维护阶段，Scala 代码库上的 Java 开发人员就会成为常态。

          回复

          1. Scala 的一个主要问题是，编写 Scava IMO 太容易了

            回复

              1. 问题是，编写代码很容易，但之后却不容易阅读/理解。尤其是当代码中有大量运算符汤和隐式时。

                回复

      4. Scala 不仅是一门优秀的函数式编程语言。它也可能是目前最好的 OOP 语言。当这两方面结合在一起时，神奇的事情就发生了。

        回复

        1. 这也是我的个人发现。我继承了一堆旧的 Scala 代码，由于没有使用 Scala 的经验，我花了一段时间才掌握了它。

          但一旦掌握了，使用起来就非常愉快。

          回复

    2. 你用它构建了哪些应用程序？图形用户界面还是网页？手机？人工智能？Scala 在这方面有强项/弱项吗？

      回复

      1. 我用 Scala 构建过各种各样的应用程序：

        – 使用 Tauri/Rust 的桌面 GUI 应用程序，但前端使用了大量 Scala.js

        – 使用 Scala.js 的 Cloudflare Workers

        – 使用 Slinky React [1] 和 Scala.js 的 Web 应用程序

        – 使用 Scala 和 Ox [2] 的高并发、基于光纤的后端应用程序

        – 使用 Scala、Spark 和 MS Synapse 针对超大数据集进行 OpenAI 模型推理

        – 使用 Scala Native 的 CLI

        [1] https://slinky.dev [2] http://ox.softwaremill.com

        回复

      2. 我们构建了全栈 Web 应用程序： 后端使用 JVM 上的 Scala，前端使用 Scala.js。在前端，一家公司使用了 React.js（通过 Scala.js 绑定），另一家公司使用了我自己的 Scala.js UI 库 Laminar。移动端是作为响应式网络应用程序实现的。我听说你甚至可以通过 Scala.js 使用 React Native，但我们还不需要，所以我还没试过。旧版的 React.js 绑定有点麻烦，但新版的（slinky.dev）很不错。其余的都很好用。

        在前端和后端使用同一种语言工作非常棒，尤其是当这种语言非常好的时候。共享模型、编解码器、验证等。同样，所有这些都是用一种非常友好的语言实现的。Scala 富有表现力但安全的类型系统在描述业务领域、编码约束等方面非常出色。

        Scala.js的唯一弱点是需要花费更多精力与JS库集成。其机制与 Typescript 相同，只需要类型定义即可，但在实践中需要手动操作。不过这并不是什么大问题，因为使用 Scala.js，你不需要像很多 JS 项目那样去做 200-npm-dependencies 的事情。很多东西都来自 Scala 语言或 Scala 库，包括不可变数据结构、强大的集合、验证、状态管理等。

        Scala 在某种程度上以复杂著称，但语言本身的简洁和优雅却让人欣喜若狂。历史上的问题在于某些函数式编程库，它们需要某种正式的/学术的思维方式才能使用。随着时间的推移，这些库确实变得更加人性化，文档也更加完善，但对于大多数开发人员来说，这些仍然是非常先进的概念。我曾经使用过这样的代码库，我不得不承认这并不是最简单的。但那是在人工智能出现之前，现在对我来说，弄懂这些东西要容易得多。但我不需要，在我现在的工作中，我们不使用这些东西。所以我建议，在深入研究硬核 FP 库之前，先学习 Scala 语言。这是一个完全可选的目标，如果你不喜欢这种风格，就不必强迫自己。

        说到人工智能，我一直在向 ChatGPT 和最近向 Claude 询问 Scala 3 和函数式编程库的情况，他们都很不错。我不会 “敲代码”，所以不了解这方面的情况，只是想请教代码片段或解释。

        回复

        1. 我认为对 Scala 的很多批评都来自函数式范式。更确切地说，它试图成为一种主流语言，而它所代表的概念对于大多数软件来说还不是主流概念。语言设计者为了让它更主流，允许开发人员以更主流的方式（面向对象）使用 Scala。也许奇怪的是，这种灵活性最终似乎损害了 Scala 的采用，因为学习混合了这两种概念的语言需要花费大量时间。

          另外，对我来说，从主观上讲，它有时确实给人一种过于抽象的感觉。你几乎可以感受到美丽而难以理解的概念所带来的学术乐趣，你可以简洁明了地表达事物，但要理解如何写出漂亮的代码却需要大量的概念。在不完全理解类型系统的情况下，与编译器斗智斗勇是一件相当令人沮丧的事，如果你还想从面向对象范式转换到函数式范式，那么最初的障碍是很难跨越的。

          回复

          1. 概念过于抽象的问题是特定 Scala 函数编程库的问题，而不是 Scala 语言本身的问题，也不是其他更简单的 Scala 库（例如 com-lihaoyi 的东西、Play、我自己的前端 Laminar 等）的问题。

            如果你需要知道 Monad / Semigroup / 等范畴论概念才能理解你的代码，那你就不是在做普通的 Scala，而是在 Scala 中做 Haskell 风格的 FP。这是一种流行的选择，很多人都对此信誓旦旦，但这完全是可选的。我个人认为这种方法的复杂性并不值得，而且我们在工作中也不使用这些东西，但仍然能享受到 Scala 的好处。

            Scala 是一门真正的多范式语言，并不存在单一文化。很多使用 Scala 的人都不使用高度抽象的 FP 库。我非常不认为 Scala 的 OOP 方面是语言设计者为了广泛吸引用户而做出的让步。FP和OOP的无缝融合是Scala的精髓所在，不需要任何第三方库，Scala就能很好地实现这一点。设计者的态度可以从他们公司创建的库（如 Play、Akka）和学习材料中得到证明，这两类库都非常倚重纯 Scala，而没有使用 FP 库。

            回复

          2. >我认为对 Scala 的很多批评都来自函数式范式。

            哪种函数范式？在 Scala 社区至少有两种常用的范式。Odersky 的愿景是 ML 风格的 FP。现在，ML 模式在现代 PL 中很常见。

            回复

          3. 我不知道。我对 Scala 的看法和你一样，但我喜欢 FSharp，尽管它也是函数式和命令式/OO。

            回复

      1. Java永远不会 “赶上 “Scala（例如，类型系统/泛型在可预见的未来不会发展）。

        但是一旦 Valhalla 落地，再加上一些额外的 JEP，Java 将非常接近 Scala 的核心。在存在空白的地方，可以通过库来填补（如 immutables.org 或其他提供持久化数据结构的库）。

        事实上，如今在我所见过的大多数公司中，典型的部署模式都是 “微 “服务，您可以通过 Spring Boot 或其他方法快速开发这些服务。不需要超复杂的代码或asbtractions，Java就能很好地做到这一点。而且您还拥有企业世界所需的所有工具。

        我认为 Scala 是教授 ML 风格编程的绝佳语言。为此，我仍然会推荐它。但是，Scala 已经不再有杀手级应用或需求，无法说服大多数人在新项目中使用它。

        回复

        1. 就像 Scala 作为 JVM 生态系统的客座语言一样，在 JVM 架构师的心目中永远不会取代 Java。

          Kotlin 在这方面有优势，因为从 Google 的角度来看，如今的 ART 实际上就是 KVM，他们会勉强更新 Java 支持以跟上 Maven 中心的步伐。

          Scala 则没有这样的优势，Python 和原生库的更新抢走了它在大数据领域的需求，这也是为什么文章中会描述这种场景的原因。

          回复

      2. 它们不在同一个游乐场。Scala 拥有更先进的类型系统（在功能上更接近 Typescript 或 Rust，而不是 Java），以及 Java 路线图上没有的编译时元编程等功能。还有一些更普通的功能，如不可变集合或 “记录 “类的复制方法。

        至于这在日常业务开发中是否有优势，那就是另外一个问题了。

        回复

      3. 可能永远不会。进展非常缓慢。

        是的，Java 从（或多或少）开始就获得了 Scala 所拥有的大量功能。但这是一个持续的过程，并不是所有这些特性都能在 Java 中得到充分的充实和完善。

        此外，Java 可能永远不会获得 Scala 已经（或将要）拥有的许多重要功能。这可能不是一些深奥的东西，比如更高的类型。而是像元编程/宏这样的东西。或者从理论角度看可能很先进，但从用户角度看其实很简单的特性（因为它们能带来更简单的代码），比如捕获捕捉（Capture Catching）。

        回复

  3. 其他语言已经迎头赶上。

    在过去，使用 Java 是一件令人头疼的事情，既枯燥乏味又充满了模板。Scala 提供了更高的效率和更多的乐趣。如今 Java 已经……很好了。Scala 仍然令人惊叹，但 Java 已经不再让人痛苦。使用一门小众语言变得更加困难。

    Scala 仍将继续存在。它是一种将函数式编程和 OO 编程完美结合的神奇语言。只是我看不到它在普及方面会有大的突破。

    回复

    1. 如果这还不够好，Kotlin 也是一种选择，它拥有一流的工具支持。很多 Java 开发人员都是 IntelliJ 的用户。

      回复

    2. Java 确实有所进步。为它的管理者们点赞。

      但我认为它仍有许多粗糙的边缘–一些在 Java 和 Scala 中难以实现（或根本不可能实现）的事情。这不一定是高级功能，比如元编程/宏。下面是一些我认为并不深奥的例子：

      * Scala拥有不可变/持久化集合，这一事实本身就改善了人们编写程序的方式和内容。

      * Scala还拥有良好的基础架构，能够以持久/不可变的方式 “修改 “数据模型图。想想深嵌套的案例类和密封特质。还有复制方法、镜头库等。Java 确实有记录和密封接口，但仍缺少与之相关的所有其他机制。

      * 概括上述观点，Scala 是不可变优先的语言，具有所有的优点。而 Java 则不然（尽管它们正朝着这个方向发展，例如 `record`s ）。

      * Java 的另一个奇怪之处在于它如何处理差异。相比之下，我觉得 Scala 更容易理解。

      * Scala 是面向表达式的。Ifs、trys 等都是表达式。你可以将这些表达式的结果绑定到变量中。而 Java 并非如此，因此在使用时非常麻烦。你必须用拳头将变量变为 null 或其他，然后确保它被分配到 if/try/… 的主体中。这只是一次糟糕的经历：(

      除此之外，还有一个文化问题：

      * Java 库喜欢返回（并期望被传递）“null”。Scala 文化中的标准库支持 `Option`。

      * 虽然 Java 确实支持检查异常，我认为这在理论上是个非常好的想法，但在实践中其实现却令人失望（例如无法抽象），因此库并不常用它。在 Scala 中，你可以返回一个 `Either`。或者在新的 Scala 3 中，我们可能很快就会拥有强大的能力系统，其中包括允许抛出 “检查过的 “异常。这就是捕获检查 https://docs.scala-lang.org/scala3/reference/experimental/cc… 研究。

      * 这可能是我的个人观点，但我觉得 Java 库比 Scala 库更难用。在 Scala 中，你只需按照类型，以直观的方式创建并使用库中提供的对象。而在 Java 中，类型对你的帮助并不大。你必须仔细阅读文档，确保在正确的对象上以正确的顺序调用正确的方法。因为类型帮不了你，所以你无法确定自己的操作是否正确，因为其他方法也能编译。

      回复

      1. Kotlin 在这些方面也做了很多改进，无论如何，与 Scala 相比，从 Java 升级到 Kotlin 似乎更容易。

        Kotlin 也比 Scala 更受欢迎。

        回复

          1. 不过，一旦撇开安卓开发，Kotlin 的受欢迎程度就会直线下降。用于 Mac/iOS 开发的 Obj-c/Swift 也是如此。

            5-8 年前，Scala 曾在数据科学/大数据工作中大放异彩，因为很多框架（如 Spark）要么用它，要么用 Python。我们之所以使用 Scala，是因为我们希望在工作负载中使用静态类型和线程（以及其他功能）。

            回复

          2. 嗯，有道理。也许我的圈子更关注 Kotlin，而我的推测太过了。

            话虽如此，但 “Github 项目数量 “和/或 “StackOverflow 标签数量 “可能并不能概括用 Kotlin 编写的 Android 应用程序的代码数量，而这正是我的想法。

            回复

    3. 我没有跟上。Java 在过去 10 年中发生了哪些变化？

      回复

      1. 很多，

        直到 Java 21，

        https://advancedweb.hu/a-categorized-list-of-all-java-and-jv…

        剩余的直到上周发布的 Java 24，

        https://www.infoworld.com/article/2335077/jdk-22-the-new-fea…

        https://www.infoworld.com/article/2336682/jdk-23-the-new-fea…

        https://www.infoworld.com/article/3491404/jdk-24-the-new-fea…

        此外，商业 AOT 编译器也受到了很大的冲击，因为现在有两个很好的选择可以免费获得：

        https://www.graalvm.org （基本上是 LLVM，但在 Java 中）

        https://eclipse.dev/openj9/docs/aot

        随着它们的出现，Quarkus 和 Micronaut 等 AOT 友好框架也在崛起。

        回复

      2. Java 现在有了模式匹配、ADT、案例类，甚至懒惰的 vals 也即将出现（”稳定值 “已在 JDK 25 中预览）。Java 还是比 Scala啰嗦得多，但如果使用得当，它看起来越来越像一种类似 ML 的语言，而不是命令式语言。

        “if “不是表达式是我个人目前的主要痛点。它能让简单的代码变得更加易读。

        回复

  4. 我想知道在一个组织中使用 Scala 在多大程度上会成为 “红旗”。不是对这种语言不敬。我用过几次，如果你全心投入 FP，那么它可能是个不错的选择。

    但是，如果你正在面试一份工作–如果一个组织选择了一个有点晦涩难懂的学术工具来构建他们的产品，这说明了什么？他们可能聪明绝顶，但你是否会陷入冗长的技术争论？他们是否固执己见、毫不妥协？他们会做出不切实际的技术决定吗？

    回复

    1. 也许这只是意味着，使用 Scala 的决定是在 Scala 看起来真的会成为下一件大事的时候做出的。如今，Scala显然已经失去了所有动力。Scala 3 试图通过吸引 Pythonistas 来解决这个问题，但我怀疑它能否奏效。它可能会作为 Spark 语言继续存在，但很难让人相信它会有光明的未来。

      另一方面，如果雇主使用 Scalaz 或 Cats，那就赶紧跑路吧。

      回复

      1. > Scala 3 试图通过吸引 Pythonistas

        来解决这个问题，你能详细说说吗？我换工作的时候，Scala 还是第二版，所以就不用了，也没跟上变化。

        回复

    2. 我们最终将绝大多数 Scala 代码迁移到了 Kotlin（以及少量 PySpark）。

      我发现 Kotlin 非常适合编写性能极佳的并发代码。实际上，在 Kotlin 中编写速度更快的代码更容易，尽管模式匹配功能不是很强大，但已经足够好了。代码也更容易理解。

      回复

    3. 他们是什么时候选择它的，为什么？10 年前，它还很不起眼。

      回复

    4. 你只需问他们一个问题就能知道答案：他们的生产代码中有没有 cats/scalaz？如果没有他们的同类，Scala 在 10 年前就是 Kotlin 和 Java 仍在努力成为的语言。

      但据我在过去几年的观察，Scala 要么被用于遗留项目，要么就是在和核心 FP 开发团队交谈。最可悲的是，即使在使用 Spark 的数据工程领域也是如此：(

      回复

    5. >我用过几次 Scala，如果你全心投入 FP，那么它可能是你的不二之选。

      它是一种混合范式语言，在我使用它（v2）的时候，写代码时完全可以不使用比现在大多数语言（包括 Javascript、Python 和 Java）更多的 FP 习语，而且这种情况很常见。那时，很多人把 Scala 当作 “更好的 Java”。

      我不知道 Scala 3 现在的情况如何，但从 TFA 来看，它仍然是一种混合语言。

      回复

      1. 同样重要的是要记住，Scala 的 FP 有两种截然不同的风格。Odersky 等人设想的是 JVM 上的 ML。此外，还有大量 Haskell 风格的 FP。

        回复
  5.  - Apache Spark在2014年选择了Scala作为在JVM上使用lambdas和模式匹配的语言。
  - Akka 选用 Scala 是因为它是一种简洁、高性能的语言，支持 Futures 或 Actors 的轻量级并发。
  - Scalaz 和 Cats 选择 Scala 是因为它是一种具有丰富类型系统的简洁语言。

    这份按时间顺序排列的列表完美地记录了随着时间的推移，Scala 的心智份额是如何缩小的…

    回复

    1. 没错，但也值得指出的是，Akka通过尝试过于明显的抢钱行为，有点自食其果–这并不只是Scala的错。不过也值得指出的是，Lightbend 是 Odersky 的公司，所以这里也许有点 Scala 的错

      回复

  6. 很棒的文章。Scala不是最流行的语言，以后也不会是。

    为 VirtusLabs 的维护工作点赞。

    为 Daniel 的课程点赞。如果你认为 Scala 很困难，那就看看他的课程吧，它们会改变你的想法。

    在构建广角分析后台时，我选择了 Scala。有时我会怀念 Spring Boot 的便利，因为所有集成都触手可及。但我用 Scala 实现了同样的功能，而且更精简，只需几个函数，非常适合。

    我对 Scala 唯一的不满就是库（Cats 2 -> Cats 3）之间痛苦的升级路径。哦，好吧。

    回复

    1. > 为 Daniel 的课程点赞。如果你认为 Scala 很困难，那就看看他的课程吧，它们会改变你的想法。

      我猜是 Daniel Ciocirlan 吧？

      回复

        1. 我不觉得它们有什么帮助或有趣。

          我想我在日常挑战中没有递归解决问题

          回复

  7. Scala 是我使用过的最棒的语言。它提供的一些简单范例（如大小写匹配）改变了我看待和编写其他语言代码的方式。

    回复

    1. 时至今日，我最喜欢的 Scala 展示是正则表达式的模式匹配：

       val date = raw"(d{4})-(d{2})-(d{2})".r
 "2004-01-20" match
 case date(year, month, day) => s"$year was a good year for PLs."。

      这比任何等价的 Java 或 Kotlin 代码读起来都要好，同时也更易于维护（例如针对多个 regex 进行匹配）。

      回复

      1. kotlin 的等价代码会不会只是：val dateRegex = Regex(“”(d{4})-(d{2})-(d{2})””) val (year, _, _) = dateRegex.matchEntire(“2004-01-20”)!!.destructured println(“$year was a good year for PLs.”) ?

        回复

        1. Scala 代码段适用于所有输入，这是在实际代码库中可以看到的。它还在匹配表达式中对 regex 捕捉进行了范围限制。对于字符串需要针对多个 regex 或特定捕获值进行测试的更复杂情况，代码的扩展性也更好。

          我猜想这个 Kotlin 代码段在进入生产代码库之前，至少需要对 “matchEntire “进行空检查。

          回复

      2. 第一行末尾的 .r 是做什么用的？

        回复

        1. 这是 Scala 标准库对字符串的方法调用，返回的是 Regex 类型。

          回复

  8. Scala 是我学习编程的第一门语言。严格来说，我是从 Java 和一些 Javascript 开始学习的，但我几乎不知道自己在做什么。Scala 通过更好的表现力、更好的迭代抽象和异步加速了我的学习。它给了我很多宝贵的经验，我很怀念它。

    遗憾的是，现在我的工具包里找不到 Scala 的位置：要么是用于 numpy-et-al 生态系统的 Python，要么是用于前端的 Clojurescript，要么是用于可移植性的 Rust，要么是用于无服务器后端的类似前端的东西（可能只是 Javascript）。长寿的 JVM 没有一席之地。

    回复

    1. > Clojurescript 用于前端，Rust 用于可移植性

      如果 Clojure 和 Rust 对你来说很好用，那就更给力了。但至少在理论上，你完全可以只用 Scala 来实现这些目的

      如果你的目标是前端，Scala 可以编译成 JS https://www.scala-js.org/。

      如果你想要可移植性，可以用 GraalVM 的原生镜像编译 Scala 程序，然后用 musl libc https://www.graalvm.org/latest/reference-manual/native-image 静态链接所有内容…

      如果你既想做前端又想随处可移植，Scala 很快就会支持编译到 WASM（与 WASI 等一起）https://github.com/scala-wasm/scala-wasm/（开发完成后将集成到 Scala.js 中）

      回复

      1. >如果你想要可移植性，可以用 GraalVM 的原生镜像编译 Scala 程序，然后静态链接 musl libc

        要让 musl 工作起来可能比较麻烦，主要静态链接（仅动态链接 libc）是一个更简单的选择。

        我用 Scala & NativeImage 构建了一个 CLI 诊断应用程序，并在其中嵌入了 Graal Python 解释器，以便编写扩展脚本。结果就是一个零安装的可执行文件，提供了一个完整的 Python 环境。我认为这很好地展示了 Scala 的优势之一，即与 Java 生态系统的互操作性。

        回复

      2. 我一直想试试 scala-js。如果有人愿意分享他们使用 GraalVM 原生镜像的经验，我会很感兴趣的。

        回复

        1. 如果有人愿意分享他们使用 GraalVM 原生镜像的经验，我会很感兴趣。

          主要的问题在于您是否使用了反射，这需要添加元数据来描述它，以便在映像中包含必要的元数据。有些库已经内置了元数据，也有一些工具可以提供帮助。

          对于构建，https://github.com/sbt/sbt-assembly 支持本地映像。

          回复

        1. 我认为 GraalVM 的专有版本在编译器中进行了更多优化。

          但 AOT 编译（本地镜像）在 GPL 社区版本中可用。

          回复

  9. 我很喜欢 Scala，多年前当它风头正劲的时候，我就很想学习和使用它。遗憾的是，当时感觉它的影响力并没有现在这么大，而且 Scala 已经被孤立在一些利基领域（如 Spark）中。用 Scala 写作如此美妙，实在令人遗憾。

    回复

    1. 我最喜欢的一直是 Akka Streams。我非常喜欢用它工作。

      回复

      1. 这让我在平淡的日子里感到温暖:)

        回复

      2. +1，这是一个了不起的库。Actors 和 Akka 栈的其他部分也很棒。可惜雷锋网对它做了什么。

        回复

    2. 我认为它实际上更多地被用于开发或多或少的普通后端。或者像 Spark 或 Akka/Pekko 这样的工具/框架。

      但你可以（而且人们大多也在这么做）从 Python 中使用 Spark，从 Java 中使用 Akka/Pekko。也可以从 Java 中使用 Akka/Pekko（但我不确定这是否常见）。

      而就业市场就在那里：

      https://functional.works-hub.com/jobs/?remote=true&tags=scal…

      https://scalajobs.com/locations/remote/

      https://remoteok.com/remote-scala-jobs

      https://betterremotejobs.com/search?title=scala

      https://readytotouch.com/organizers/scala/vacancies?remote=1

      https://www.levels.fyi/jobs?searchText=Scala&workArrangement…

      https://www.linkedin.com/mwlite/search/jobs?keyword=Scala&lo…

      https://discord.com/channels/629491597070827530/629546253381…

      https://discord.com/channels/632277896739946517/840255868096…

      回复

    3. 对我来说，spark 是我学习 spark 的原因，因为 Java Api 令人讨厌。

      但我不喜欢在 java 和 scala 以及最近的 kotlin 之间切换。语法模型在我脑中的切换让我抓狂。）

      回复

  10. 我认为Scala在10到5年前有很大的发展势头。很多人选择 Scala 来开发新的应用程序，也有很多人在用 Scala 重写现有的应用程序。但后来发生了一些事情，Scala 失去了动力，再也没有人对 Scala 感兴趣了。

    回复

    1. >但事情发生了

      ，甲骨文开始大力投资 Java。谷歌选择 Kotlin 作为 Android 的语言。

      但 Scala 并没有因此停滞不前。正如这篇博文所言，Scala 还打算继续前进。例如，https://docs.scala-lang.org/scala3/reference/experimental/cc……可能是该语言历史上最具影响力的发展之一。

      回复

    2. 如果不需要 JVM / Java 交互，几乎每个领域都有更好的替代方案。

      数学方面的 Julia。

      使用 pandas / polars 的 Python。

      Rust 与 polars / actor 框架。

      Go 用于简单的系统工具/API 开发。

      用于系统编程的 Zig 和 Rust。

      用于功能性网络开发的 Elixir / gleam。

      JS / TS 适用于一切。

      回复

      1. 所有这些语言对于很多人来说都能很好地满足上述用例。

        但 Scala 的优势之一是通用性。您也可以用它很好地处理所有列出的用例。只需一种语言。(也许系统编程是个例外–Scala Native 仍然需要跟踪 GC）。

        另外，值得注意的是，Scala 比 Julia、Zig 和 Elixir / gleam 更流行/主流/受支持/拥有更大的社区。如果 Red Monk 值得信赖的话，它甚至比 Rust https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2 更受欢迎… >如果您不需要 JVM / Java 互操作

        OpenJDK 也很不错，即使这不是使用它的严格要求。经过实战检验，易于调试，等等… 通过 GaalVM 的原生镜像可以进行 AOT 编译。

        或者你也可以试试 Scala.js 或 Scala Native（与 JVM 无关）。

        回复

        1. >所有这些语言对于很多人来说都能很好地满足上述用例。但 Scala 的优势之一是通用性。您也可以用它很好地处理所有列出的用例。

          我认为 C# 已经占据了 “万金油 ”的位置。

          回复

          1. 这不是一门语言可以占据的领域。

            回复

  11. 大约十年前，我曾广泛使用过 Scala，现在我仍在等待我喜欢的 Scala 功能在我日常使用的语言中出现。

    我非常怀念它。

    回复

      1. * 不可变优先

        * 标准库中的不可变/持久化集合

        * “修改 “不可变深层嵌套类/密封特质的机制。你有复制方法，你有镜头库。使用起来非常简单、舒适。

        * 面向表达式。if/try/等表达式可以绑定到一个变量

        * 用更少的字符写出同样的想法/程序，同时不失可读性

        * 更好的工具： Scalafmt 广泛使用，在 IntelliJ 中得到支持，而且非常出色。Scalafix（一种也能自动修复某些问题的语言转换器）用得比较少，但也很不错。

        * 构建工具：虽然我不喜欢 sbt，但 Mill 是比 Maven 或更糟糕的 Gradle 好得多的构建工具。还有 scala-cli，它不是一个构建工具，但如果你有一个简单的单模块项目（即没有子项目/子模块），它可以像构建工具一样工作。

        回复

        1. 另外，在我使用过的语言中，集合 API 是最好的！

          回复

        2. 谢谢，这包含了大部分内容。我还要补充 Twitter 提供的 Algebird 等优秀库，以及使用 Spark 大规模处理数据类型的能力。

          回复

      2. 你可以只用类型而不用代码来编写整个程序？

        尽管如今在 typescript 中也可以做到这一点。

        回复

        1. 如今，类型系统的表现力足以编写实际的程序，这已经很普遍了。

          Typescript 的类型系统甚至是图灵完备的。

          无论如何，使用类型检查器作为运行时并不实用。

          回复

          1. 不是有人在 Typescript 类型系统中实现了 Doom 吗？

            回复

      3. 对我来说，元编程能力（包括基于类型和宏的）才是杀手锏。这并不是因为我直接使用了它们，而是因为它们允许库作者创建极富表现力的库。

        回复

  12. 我的主要抱怨是集成开发环境支持太差。>我们承认还有很多工作要做。IntelliJ团队正在努力为Scala 3提供最好的支持，你可以期待在接下来的几个月里有更多改进。

    很高兴听到这个消息。我还以为 Jetbrains 已经为了 Kotlin 而彻底放弃了 Scala，所以我很高兴他们仍然愿意支持 Scala。

    回复

    1. >Shapeless如此随意地破坏了一切。

      谢天谢地，Scala 3 中不需要 Shapeless 了。> Jetbrains已经完全放弃了Scala

      还好没有。他们定期发布新版本，对 Scala 3 的支持也在不断改进。如果你发现了需要修复的 bug，他们也欢迎你提交 PR。(Scala 插件的代码库使用的是 Scala，因此社区很容易做出贡献）。

      回复

      1. 我所在的公司仍然坚持使用Scala2，所以我的消息可能有误，但我听说Scala3的元组不能完全取代Shapeless，比如缺少了LabeledGeneric等价物？

        回复

  13. 我喜欢 Scala，在我职业生涯的大部分时间里，我都把它作为我的主要语言。

    随着其他语言的迎头赶上，scala 的影响力正在减弱，但在某种程度上，也许让那些自诩为精英的人转而使用 rust，将意味着留下一个更务实、不那么引人注目的用户群，而那些让 scala 变得有毒的智力单打独斗也能在其他地方找到归宿。

    如果我今天才开始使用 scala，我会更倾向于使用 python、typescript 或 go，这取决于使用情况。(我仍然认为 rust 被过度设计、过度使用和过度规定，只有极少数人能从编写它中获得报酬）

    总之，我希望它能变成 COBOL，我可以为解决银行的技术债务问题收取高得离谱的费用。

    回复

  14. 编译时间太疯狂了，根据我的经验，甚至比 Rust 还糟糕。

    回复

    2. 说实话，这并不是对Scala的很大冒犯。比 rust 差很容易。

      根据我的经验，Rustc 是一个优化得非常好的编译器，仅次于 Go。在使用 Maven / Gradle 时，它也能击败纯 Java。它之所以名声不好，是因为 Rust 项目是完全从源代码编译的，因此 Rustc 需要编译的代码通常比使用二进制依赖关系的语言多 100 倍。

      fclones 包含所有依赖关系的总长度约为 50 万 LOC。在我的机器上，冷编译和链接需要 9 秒钟。

      我已经很久没用 Scala 了，但上次我们使用 Scala 时（Scala 2.12 + gradle），编译时间简直惨不忍睹。一个包含约 2 万行 Scala 代码和一些 Java 代码的项目需要 5 分钟才能编译完成，而且增量编译完全不起作用（可能是因为 Gradle 无法理解 Scala 的依赖关系）。

      回复

      1. >它也打败了使用 Maven / Gradle 的纯 Java。

        我不这么认为。

        Java 的编译速度快得离谱。

        https://mill-build.org/blog/1-java-compile.html

        据此，javac 本身的编译速度可达每秒 10 万行，而 Maven/Gradle 则要慢一个数量级。

        我找到的关于 Rust 的唯一信息提到了 5k 行/秒的速度（在另一台计算机上），但它最多与 java 编译工具的速度大致相同，甚至更慢。

        回复

        1. Java 的编译速度可能快得离谱，但 maven/gradle 会让它爬行。

          > 我找到的唯一关于 Rust 的信息提到了 5k 行/秒的速度（在另一台计算机上）

          在奔腾 III 上？

          让我们看看它在 M3 Pro 上的表现：

              cargo loc --filter-platform=aarch64-apple-darwin    
    ...
    Total lines: 961318
    (783408 code, 77484 comments, 100426 blank lines)
    cargo clean
    cargo build
       Compiling libc v0.2.155
       Compiling autocfg v1.1.0
       Compiling cfg-if v1.0.0
       Compiling proc-macro2 v1.0.69
       Compiling unicode-ident v1.0.12
       Compiling memchr v2.6.4
       ...
       Compiling dtparse v2.0.0
       Compiling fclones v0.35.0     (/Users/piotr/Projects/fclones/fclones)
       Finished `dev` profile [unoptimized + debuginfo] target(s) in 9.75s

          看起来大约为 80k LOC/s。不错。

          如果纯 javac 也能达到 100k LOC/s（我相信这绝对是可能的），但 “Maven/Gradle 要慢一个数量级”，那么我的观点就成立了。没有人使用纯 javac 来编译大型项目。

          回复

    3. Rust 的编译时间已经不像以前那么糟糕了。

      回复

        1. 有基准测试的链接吗？

          Rust 发布了他们的性能数据：https://perf.rust-lang.org/dashboard.html 我在哪里可以找到类似的 Scala 数据？

          回复

    4. 增量编译器使得这基本上不是问题

      回复

  15. >值得庆幸的是，大量使用符号运算符已经过时了。

    我想这是指操作符重载。我认为 “a + b – c ”看起来比 “a.add(b).sub(c) ”更可读，当一种语言允许我为向量/矩阵定义自己的运算符时，我很高兴，但我也有一个好奇心：它们在数学语境之外有好的用处吗？例如，我从未听说有人称赞过 C++ 中的 `<<“ `>>`。

    回复

    1. 这主要是因为库实现了自己的符号，例如 ~>、~>>、>->、λ

      每个符号都是该库所特有的，会让新开发者无所适从。

      回复

    2. 大部分代码都不是数学。我更喜欢语言有数学 dsl，只有在数学 dsl 中，数学运算符才可用。

      实际上，相对于文字，我更喜欢符号（+ 代替 append、:代替 as、<代替 extends、->代替 function 等）。只是它们需要有稳定的含义，这与运算符重载/数学有冲突。

      回复

  16. 承认该语言不再像以前那样流行需要很大的谦逊，因此我们要为这一点鼓掌。对于 Scala 来说，让初学者更容易接受这门语言是一个有趣的转变，我认为这会对这门语言产生积极的影响。

    回复

  17. 在 Java 和 Python 一年比一年好，以及 Go、Rust、Kotlin 和 Swift 的异军突起之间，2025 年的此时此刻，Scala 差不多已经死了，对吧？

    回复

  18. Akka死了吗？TFA在多处暗示了这一点。

    回复

    1. 我相信人们大多是在它成为专有技术（BSL）之后才对它失去兴趣的。我知道，这就是我多年未碰它的原因。

      回复

      1. 当许可变更发生时，我的一个项目已经进行了一半，结果我不得不放弃 Akka。幸运的是，我对 Actor 系统的要求很低，基本上只是在多线程单进程中进行消息传递，所以我自己写了一个简单的 Actor 系统库。Scala 让这一切变得相对容易。

        回复

    2. 很久以前，随着将 Actor 作为一种编程范式的热潮逐渐消退，akka 也变得不那么流行了，后来，akka 最终采用了非开源的 BSL 许可，这使得包括我们在内的许多用户转而使用 Pekko（一个社区分叉），该分叉仍在开发和维护中，但同样，Scala 的这一分支已经过了它的鼎盛时期。现在，Scala 为并发工作提供了更多也可以说更好的库，而 kyo / ox / caprese 等更酷的东西也即将问世。

      不过，akka aka pekko 仍然完全可用。

      回复

      1. 我一直在努力将基于 Pekko 的数据管道添加到我的副项目中，这是一个非常强大的系统。裸 “演员很少使用。通过流，你可以控制并行性、反向压力、添加批处理、重试等。这也是为什么它在接收海量数据的系统中如此受欢迎的原因–日志处理、物联网遥测。

        你指的是哪些库能做到这一点？只是好奇。

        回复

        1. 我指的是 FP 库，如 Cats Effect / FS2 / ZIO 等–它们并不能真正实现 Akka / Pekko 擅长的功能，如多机并行，但现在的传统观点似乎是，从这些库开始，如果需要的话再升级到 Pekko，而不是在不需要 Pekko 的强大功能时从一开始就用它来架构系统。

          我不知道我个人是否同意这种说法，我在使用 Akka（甚至是原始角色）方面的体验要好于使用 FP 库，但我所提到的绝对是我在社区中观察到的公开活跃部分的普遍氛围。我们必须记住，有很多公司和开发人员从不在公开场合谈论他们正在做的事情，因此我的看法当然会有偏差。

          最近，我自己的专长越来越多地转向前端/Scala.js，如有不妥之处，敬请原谅/指正。

          回复

          1. 假设 Cats Effect / FS2 / ZIO 比 Akka / Pekko 更简单是有问题的。有一种假设是，Akka 生态系统要求整个系统都使用该生态系统提供的各种功能来构建，而实际上，如果这是唯一的选择或整体偏好，它很容易扩展到简单的微服务。

            使用纯函数库的一个原因是希望避免Akka/Pekko的一些缺陷。在很长一段时间里，使用 Akka 意味着无法依靠 Scala 类型系统来检查行为体之间发送的消息，而对于那些因高级类型系统而被 Scala 吸引的人来说，这是一个致命的缺点。

            总而言之，FP 库和角色系统库几乎是解决问题的两种截然相反的方法。

            回复

          2. 这是两个不同的问题（远程/集群与本地并发）。Shardcake + ZIO 比 Akka remoting + akka 好得多

            回复

  19. Scala 的衰落还有另一个原因–用 Scala 写 Spark 代码的人少多了。在高峰时期，我认为Spark占了Scala增长的很大一部分

    回复

    1. 这对Scala来说其实是件好事，很多人都说’哇，Scala太可怕了’，后来我发现他们在做黑魔法的Spark代码库

      回复

  21. Scala有一个很有用的作用：如果你想去某个地方工作，结果发现他们用的是Scala，而且没有迁移，那么你就知道不要去做这份工作了。

    回复

    1. 我的做法恰恰相反，我找了一份可以使用更多 Scala 的工作

      回复

  22. Scala 是一门了不起的语言，我已经专业使用它十年了。但它有三大问题：

    1）语言太不稳定–如果你想长期使用这门语言，这看似是一大优点，实际上却是一个大问题。

    2）围绕它的工具不是最好的–集成开发环境中的语法支持问题、sbt 仍然是一团糟。与 Rust 或 Go 等现代产品相比，它看起来并不出色。

    3) 竞争对手正在迅速迎头赶上–现在不是 2010-2015 年，Scala 的竞争对手一直在快速发展，并吸收了大量 FP 特性（模式匹配 HOFs 等），这些特性让 Scala 脱颖而出，但与此同时，Scala 也拥有更大的开发者群体、更成熟的框架等。现代 Java 和 Kotlin 就是一个很好的例子。Scala 仍然很棒，但差距已经不像十年前 Scala 最受欢迎时那么大了。

    当然，要找到并招聘到有能力的人才仍然很难，尤其是在使用 Cats/ZIO 而不是 Java+ 风格的 FP 重型项目中。我猜这就是为什么我们看到用 Scala 编写的新项目越来越少的原因（其中大部分可能是 Spark），而且在许多公司中，Scala 正在成为等待重写为 Java 等语言的传统语言。

    “Scala将继续发展，直到士气提升”

    回复

    1. > 1）这门语言太不稳定

      幸好现在不是了。他们振作起来，自 2021 年 5 月 Scala 3.0.0 发布以来一直保持兼容性，至今已近 4 年。

      https://github.com/scala/scala3/releases/tag/3.0.0

      Scala 3.x 将在整个 3.x 系列中保持兼容（想想语义版本）。目前还看不到 Scala 4（与 Scala 3 断开）。

      另外，Scala 3 和 Scala 2.13 的 JAR 也是相互兼容的，这有助于过渡。

      > 2) 其周围的工具不是最好的

      sbt 可能不太好。但 Mill 比 Maven 或 Gradle 都要好得多。尤其是 Gradle。Bleep 也很有前途。

      Scalafmt 得到了广泛应用和喜爱。Scalafix–内核/修复程序–用得比较少，但质量仍然不错。

      回复

      1. 在我看来，像 sbt、scalafmt……这样的工具其实还算不错，但 LSP 用起来很麻烦。

        我只有在 Intellij 上才能提高 scala 的工作效率，只要我看一眼 LSP 的金属实现，我的工作效率就会直线下降

        。更糟糕的是，大多数优秀的 AI 编辑器都基于 VSCode，这意味着我要么得忍受它，要么在任何时候编辑代码时 alt-tab 到 intellij。

        回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注