前言

今年上半年，我当时正在建立一个数据工程师的队伍，并且需要选择一门编程语言。Scala那个时候看起来是一个非常好的选择—我们一开始用Spark试验了—但我们遇到了一些障碍。我尝试调查了这个领域的一些想法，但没有一个是有建设性的。我读的文章里面的想法不是有偏颇的，就是过时的，或者两者都是。我现在写下这篇文章是希望帮助之后有人和我遇到一样的情况，需要弄清或者评估Scala对建设一个数据科学或者数据工程师的队伍的作用。

在这篇文章里，我会从数据和人的角度来讨论Scala生态系统的主要几个部分。我在GitHub上面抓出时间序列的数据来帮助分析，同时尝试解决我之前的一些担忧。我同时联系并征求了领导Scala团体的一些专业人士的意见，其中包括Martin Odersky. 他们都非常慷慨地贡献自己的时间，也非常高兴分享他们的想法。

我会公平地呈现一些事情，但是我需要申明这些看法都是我的个人意见。我没有做过对Scala系统和开源数据任何有显著推进的贡献，但是在Scala之前，我一直使用Haskell语言。我在DataScience Inc.—一个洛杉矶的数据科学公司招聘并培训了一个六人团队成功地单独使用了Scala语言来处理事情。

Java的所有权和SMACK框架的崛起

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

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和Kafka的发展

在新的观察人数和拉请求，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是一个跨功能的框架，除了数据流动，还包括一个内存中的分布式计算引擎，数据帧图计算,和机器学习库。

Dotty – 一个行业新标准？

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中一些不可思议的语法。

自由言论 vs. 没有暴力的沟通

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

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

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

是否使用Scala, 消除一些FUD的错误

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

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

今年二月，比较不为人熟悉的Scala的母公司Typesafe更改了它的名字，为Lightbend. 这些担忧对我来说明显夸张了。Lightbend的首席执行官Mark Brewer在下面这篇博客中明确指出Lightbend还有会继续致力于Scala这一语言和其团体。当我对Brewer提起这一长久的担忧，他说道：我们很庆幸拥有一个非常迷人的声音围绕着Scala这个团体，这件事很大程度意味着Lightbend所做的事情得到了大量的报道。比起没有任何的互动，我们宁愿拥有的是用户的抱怨。

2. 对开发人员培训的担忧

这个问题其实是很有根据的。比许多其他语言，Scala有一个更艰难的学习曲线,缺乏集中的新员工培训材料和社区论坛(例如像Rust拥有的)是一个目前存在的问题。今年3月, 瑞士洛桑联邦理工学院宣布建立一个Scala开源的一个平台，称为Scala中心(由Lightbend，IBM，和Verizon和其他组织提供支持)。

3. 对文档改进的需求的担忧

希望Scala中心的引进也可以同时包括对Scala文档的改进的一些努力。我和Scala中心的执行官Heahter Miller聊过，关于文档她是这么说的：

“对我个人来说，文档是一个长期的担忧，我也认为公司需要聘请一位技术写手来解决这个问题。对于5年以来都非常热情地编辑很多开放式的Scala文档的我来说，编写文档绝对不能是一个志愿的任务。然而，因为Scala中心是有管理层的，所以也不是我个人能决定是否分配资金并聘请一位专业的写手来改进文档。这是一件需要提议，讨论并在即将到来的委员会会议中表决的事情。在此之前我无法做出任何的行动。”

Scala中心现在有3.5个全职工作人员，作为瑞士洛桑联邦理工学院的一部分，中心有一套相当严格的聘请规则（例如员工必须是联邦学院中的医院，工资并不可观等）。中心从一些不官方的渠道例如个人，公司或者每周的委员会会员听取意见。这些建议都会被转化为提议，每三个月都会被提交到委员会会议上。委员会会员会就这些提议进行投票，把投资者的担忧都考虑在内，之后就会根据中心拥有的人力去完成这写任务。

4. 对Scala团队发展的担忧

这些担忧某些程度上也是非常有根据的。除了Scalaz episode，对论坛讨论人数的下降抱怨的人数也在增长。Miller说她自己也有联系一部分人，大多数是女性。当她谈到这件事情的时候，这些人感受到

“不只是恐吓，有时候也感到丢脸？，她们看到人们一个接一个地退出，她们也选择不参与。她们感觉整个论坛充满敌意，而且这些敌意比其他她们才加的社区多。”

因此目前为止，Scala中心的重点项目包括对Scala/Dotty移动的放松和提高高层管理（她们最近重启了Scala改进项目）。中心现在也准备宣布推出新的Scala平台和重建相应的数据库。

5. 对聘请Scala开发人员的担忧

这问题是很有根据的。如果你预见到需要增加一个很大的团队或迅速增长一个团队迅 ， Scala可能不是一个好的语言选择。相对于其他主流的功能性语言，Scala开发人员也往往是高需求的。

专业人员的分布也非常合理。大部分工作人员主要在科技中心,小部分分散在全国各地。不过,除了湾区,洛杉矶,纽约,西雅图,你很有可能需要适应远程团队工作。经验丰富的Scala开发人员也有很好的自我价值的意识,尽管同时雇佣几个高级Scala开发人员是有可能的,但是用成熟的Scala开发人才来填补你的整个团队并不简单，成本也不低。这和标准的建立Java开发人员团队策略不同，无法同时雇佣大量的成熟的人才。

图10. 来自：DataScience.com

一门语言的成长

Scala这个群体非常有效率。我们同时看到一个大体的行业向功能性编程的转变，用时也给现代科技平台的其他部分带来一些复杂性的增长，这也许是一件好事。Scala被明确认为是在分布式数据处理的一个合适的镶入，现在也拉动着功能性技术的在主流上的运用。在这个方面，她很大程度得利与充满热情的功能性编程语言这个群体。

我不认为Scala这个团体希望看到Scala “拓张到所有企业”。相反的是，我交谈过得很多人都有一个共识就是Java类型的一个走向是不太健康的。Java占据了主导地位然后停滞了一个世纪对编程来说并不是一件好事。所以，继续实验，争取增长，抵抗早期标准化，简化语言而不是堆积语言的拓展--这才是健康的走向。所以清楚，可编辑，可以理解地成长，向一个可以接近却无法达到的最优境界迭代才是Scala发展的最健康的走向。

免责声明：转载自网络 不用于商业宣传 版权归原作者所有 侵权删

制图网(www.makepic.net)，专业的logo免费设计在线生成网站，全自动智能化logo设计，商标设计，logo在线生成！

欢迎使用制图网制作属于您公司自己的logo，不仅专业而且经济实惠，全方位满足您公司品牌化、视觉化的需求。