剖析Scala|数据工程师评价Scala语言的现状和发展

原文作者：Chris Mckinlay

翻译：Kristin

编辑：zz

大数据应用授权转载

Scala非常依赖于Java系统。去年对Java来说去年唯一一件最重要的事情就是甲骨文告了谷歌。Java系统和整个行业对需要许可证来创建一个兼容的API实现感到非常兴奋。尽管谷歌赢得正大光明，但是因为令人失望的联邦法院在API 版权上的决定，核心问题还是没有得以解决。

对Java来说更大的问题是甲骨文对这门编程语言私人拥有的束缚和对应的管理权的缺失。Java在过去这个世纪发展缓慢（Java6和Java7期间有五年的间距），甚至有人对Larry Ellision写过请愿书说“把对Java EE的发展当成是全球IT行业发展的一个重要的部分”。结果是，Java渐渐在一些中心区域被一些新的开源语言抢占了市场份额，例如Scala.根据Indeed.com上的整合数据，从2012年到2016年，有关Scala开放的工作数量增长了超过500%，然而在同个时间段，有关Java开放的工作数量降低了33%。

这个趋势的早期迹象最明显的可能是在SMACK 栈(Spark, Mesos, Akka, Cassandra, Kafka)出现在分布式空间数据处理。 这些平台架构都是用Scala写的。Scala用来编辑Spark，从而在对的时间成为一门对的语言 – 同样的Spark现在帮助推广Scala的应用。语法上， Spark和Scala集合API是几乎相同的，使用Scala对Spark来说就像是个力量倍增器。

除了Scala之外，以数据为中心的应用程序和可组合的并发原语的日渐重要性引起了对功能编程语言Clojure,Erlang,Haskell的广泛兴趣。

Scala在流动数据和微服务的趋势中的重要性也非常清楚：在Lightbend最近对全球2151名JVM开发员的调查中，运用微服务的Scala开发员比Java的多出50%。在所有使用微服务的开发员中，35%使用Akka, 30%使用Kafka, 19%使用Spark.

我通过从Akka, Kafka和Spark的GitHub数据库提取他们每天的时间序列数据来进行比较。从三个分别的时间序列数据我观察：总共的新的观察人数，拉请求（Pull  Request）和改变(Commit)[Office1] 。每个数据的跨度分别从13年的9月30号到16年的9月30号。为了可观察性，我把这些时间序列数据表达成一条2周的平滑的移动平均线。本文进行的查询是基于GitHub上用谷歌BigQuery SQL接口存档的开源数据。所以查询的代码可以在这里看到。

图1 GitHub上Spark，Akka和Kafka每日的新的观察人数的时间序列数据。 来自: DataScience.com.

图2：GitHub上Spark，Akka和Kafka每日的拉请求的时间序列数据。 来自:DataScience.com.

图3. Spark，Akka和Kafka每日的改变的时间序列数据

来自: DataScience.com.

在新的观察人数和拉请求，Spark显然是最活跃的选项 。这不该是一个惊喜。在数据社区里面，Spark仍然是最活跃的开源项目, 从2015年到2016年，代码库的贡献者增加了67% 。Scala继续作为Spark的第一编程语言,Python紧随其后。

对拉请求数据来说，Kafka似乎也赶上了Akka。值得注意的是，因为Confluent接管了Kafka的维修，一些开发转移到了Java。 同时Kafka围绕着流动数据，成为了成批ETL系统的替代。

此外，Kafka允许你构建一个分布式系统，甚至担保你一次交付。还有，你可以发送保持格式的二进制数据（例如，在Avro）。如果你要用像Scala一样强类型的语言，你可以保留所有数据的形式。这明显和JSON转储有很大的区别，JSON需要你重新解析你的数据。（生成JSON 数据是ETL系统中的样本文件的主要来源）。

看起来很多像DataScience一样的很多初创公司都是Kafka的新用户，用Kafka作为微服务的一个可伸缩的管道。Confluent的思维也反映了这一点。Jay Kreps在他的今年早期的博客也说明了这一点。

在这片博客中有几个有意思的观点是：

·      Spark涌现的每日拉请求的数量的增多都相应发生在每一个发布日期前的一段时间

·      在2016年一月Akka的commit有大幅增长。（总共是2008份commit）。这看来有部分主要的house清理 – 维修者合并大量在Akka的commits和HTTP到主分支上去。

·      这不是一种同类对比。所有三种语言都是多方面的。Spark是一个跨功能的框架，除了数据流动，还包括一个内存中的分布式计算引擎，数据帧图计算,和机器学习库。

Martin Odersky一直领导着Dotty的工作。 Dotty是一种创新的，基于Dependent Object Types（DOT）演算（基本上是Scala的简化版本）和函数式编程（FP）数据库社区的研究编译器。

从事Dotty开发的团队已经对现有技术进行了一些显着改进，特别是在编译时间方面。我问Odersky关于Dotty架构的创新和并如何帮助最终用户。这是他说的话：

有两件想法：第一，它与正式基础密切相关，可以给我们更好地指导如何设计一个声音类型系统。 这将为最终用户带来更少的惊喜。 第二，它具有基本上功能架构。 这使得它更容易扩展，更容易正确，并将带来更强大的API，其中编译器有作为IDE和元编程的服务的功能。

虽然Dotty开辟了许多有趣的语言可能性（特别是全光谱依赖类型，la Agda和Idris），Odersky仍然选择优先使它对社区有立即的作用。 语言差异相当小，并且大多数是为了简化语言（如删除过程语法）或修复错误（不健全的模式匹配）或两者（早期初始化器）。

有趣的是，Odersky实际上具有建立人们使用的编译器的悠久历史。在他完成博士学位之前，他把一个Pascal编译器卖给了Borland。他之后完成了博士学位。在Niklaus Wirth （Pascal的创建者）下，他在IBM（E语言，后来被商业化）完成了一些博士后的工作，然后捕获了功能编程（FP）的错误。他继续写Pizza（用Philip Wadler的Haskell和Java Generics fame ）和Funnel。那个时候没有人使用那些，但他和Wadler 发明了GJ编译器，当然，也引到了Java的广泛使用。他也写多个Scala编译器（Dotty是第五或第六）。我这里可能说漏了一些事，但重点是，他是一个相当可靠的人。

然而，我不能拒绝询问他是否有任何机会，在某个时候全谱依赖类型会结束在Scala 。 这里是他的回答：

“永远不要说不 :-）， 事实上，我们目前正在与Viktor Kuncak合作，将Leon程序与Scala集成，它需要比我们现在更丰富的依赖类型。 但它目前在严格的研究阶段，并会有一个完全开放的结果。”

Scala和Dotty团队正在密切合作以实现Scala 2.x和Dotty的融合，他们表示他们非常重视连续性。Scala 2.12和2.13具有解锁在Dotty中出现的特性的语言标记（例如，存在类型），而Dotty编译器具有Scala 2兼容模式。 我们有理由相信甚至会有一个迁移工具。

图4：GitHub上每个编译器的新的关注的时间序列数据。

来自：DataScience.com

图5：GitHub上每个编译器的拉请求（PRS）的时间序列数据。 来自：DataScience.com

图6：GitHub上每个编译器的commits的时间序列数据。

来自：DataScience.com

我还通过分析来自它们各自的GitHub的时间序列数据来比较两个编译器（以及Typelevel的fork）。一般来说，新的观察者（很可能来自Dotty的文档和Hacker News的帖子）是这些时间序列数据中最有趣的事情。

Lightbend是支持Scala和PLAY反应JVM框架的公司，由Odersky，前扑克冠军和软件工程师Paul Phillips和Akka创作者JonasBonér创立。该公司最初被命名为“Typesafe”以反映其功能性编程根源，并在2016年2月改名为“Lightbend”。我与Lightbend首席执行官Mark Brewer谈论了该公司在Scala的工作，这是他说的：

“Scala 2.12一直是Lightbend和许多外部贡献者的重要投资。为了利用Java 8中的功能，后端已被完全重写，（因此，在将其编译为Java字节代码时，不必将Scala转换为Java）。

此外，2.12带来了一个新的优化器，执行更深的静态分析，以消除功能编程中常见的高阶代码模式的开销。现在2.12已经在最后（希望） （希望是），团队也开始2.13的工作。 2.13功能集仍在定义，但它将包括一个新的集合库（这是社区一直在要求的）和其他来自Dotty的功能。”

Lightbend现在正在进行2.12版本上的发布，特别是表明了Scala对FP社群需求和输入的反应。

最后，有趣的是，随着Dotty越来越接近能够编译主要Scala生态系统的大部分，开发周期节省大量时间的这一前景已吸引了许多公司，并表示尽快地发展Dotty和Scala的兴趣。 当Dotty实现与scalac的功能奇偶校验时，会发生什么将会是相对有趣的 。

Scala是一种多范式语言，它的社区就是一种反映。 Martin Odersky的Scala的最初目标是证明功能代码可以根据面向对象的原则进行组织。 除了上面列出的大量转换Java转换的项目之外，这个设计也导致了从纯函数编程（FP）语言（例如Haskell）的转换的采用。

社区的分割：Cats和Scalaz

历史上，Scala FP 社区一直由Scalaz代表，它仍然是GitHub上最有名的Scala库之一。从Haskell外派到Scalaz工作的开发员一直以来都有相当大的数量；自从Scalaz成立以来，社区一直在一定程度偏向于全面移植Haskell类型的FP 模式和语法等到Scala。

在2014年底，在新的“行为准则”（CoC）失败后，社区开始崩溃，Edward Kmett这篇文章表示。

Typelevel的人事实上确实创建了一个新的FP 库（Cats）。虽然Cats不是Scalaz的直接分支，但是它使用许多相同的概念，并且或多或少是Scalaz一个直接的竞争对手。

图7：GitHub上Cats和Scalaz的新的关注的时间序列数据。

来自：DataScience.com

图8：GitHub上Cats和Scalaz的PRs的时间序列数据。

来自：DataScience.com

图9：GitHub上Cats和Scalaz的commits的时间序列数据。

来自：DataScience.com

对于PRs活动度量的总体大小，Cats大于Scalaz，但是其中一些度量可能是由于库的年龄。然而，就每天的commits量和每天的新观察者而言，Scalaz似乎没有显着减少。所以，似乎社区上一些人的恐惧已经过去了。事实上，Scalaz和Cats的存在对下游库造成了许多麻烦，尽管大多数人通过包括对FP依赖（如FS2和scodec所做的），或者通过shims或source-代码级预处理找到了可行的解决方案。

另一方面，也许Tony Morris正确的说过，Scalaz项目与Cats在动机上有很大的不同，最终两个库都有他们继续发展的空间，并在Scala社区中服务与不同的需求。Cats一直努力保持轻量级和模块化（见这里和这里），以及避免Scalaz中一些不可思议的语法。

Scalaz CoC失败的最大的原因是，第一个被禁止介绍Scalaz CoC的人恰恰是项目的创始人。然而，更大的原因可能是，CoC被强加于一个已经运营了7年的社区，而不是作为新事物被引入。以这种改变群体话语的模式可能等于要求参与者加入一个完全独立的运动。两个最可能的结果是平淡拒绝CoC，或（这是发生在Scala内部）CoC被忽略，一直地负面性拖动论坛活动到接近停止。

Scalaz戏剧暴露主要是（最近在Scala辩论论坛上最近才出现的）对开源软件开发中的行为守则的哲学分歧。 一方认为想法是相等的，这些想法如何传达不太重要（今年的辩论在LambdaConf上引起了争议）。 另一方则认为，他们不能接受仅仅因为它是以粗鲁或侮辱性的方式传达的就忽略批评。

另一方认为暴力沟通拖累了整个社区，因此可接受的沟通的概念应该受到CoC的限制。 我可以从个人经验中说，我与Typelevel的人员的来往都是非常的积极 - 我的团队中的每个人都是一样的感觉。 Typelevel对在采用他们的项目的新人非常耐心，特别是使用Cats工具的新人。

像任何主流编程语言一样，Scala吸引了很多权威人士和随之而来的“Scala很棒”，和“Scala已经死亡”的评论（很明显是来自一位Java开发者的评论）。如果你在考虑学习Scala或者聘请一个Scala的团队，你必须考虑两个方面并作出你自己的判断。在排除一些明显FUD的错误，我想要解决一些人们共同拥有的担忧。

1.    对Typesafe名称更改和Scala管理权的担忧