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

原作者:克里斯·麦金莱

翻译:克里斯汀

大数据应用授权转载

前言

今年上半年，我正在组建一个数据工程师团队，需要选择一种编程语言。Scala在当时似乎是一个非常好的选择——我们最初用Spark尝试过——但是我们遇到了一些障碍。我试图调查这一领域的一些想法，但没有一个是建设性的。我在张文读到的观点要么有偏见，要么已经过时，要么两者兼而有之。我现在正在写这篇张文的文章，希望能帮助像我一样遇到同样情况的人，并需要找出或评估Scala在建立一个数据科学或数据工程师团队中的作用。

在这个张文，我将从数据和人的角度讨论Scala生态系统的主要部分。我在GitHub上抓取时间序列数据帮助我分析，试图解决我之前的一些顾虑。同时联系咨询了一些领导Scala集团的专业人士，包括马丁·奥德斯基。他们都慷慨地贡献了自己的时间，并非常乐意分享他们的想法。

我会公正的陈述一些事情，但是我需要明确这些观点是我个人的观点。我没有对Scala系统和开源数据做出任何重大贡献，但在Scala之前，我一直使用Haskell语言。我在洛杉矶的一家数据科学公司——数据科学公司(DataScience Inc .)招募和培训了一个六人团队，并成功地使用Scala语言独自处理事情。

Java的所有权与SMACK框架的兴起

Scala严重依赖Java系统。去年，Java最重要的一件事是甲骨文起诉谷歌。Java系统和整个行业对于需要许可证来创建兼容的API实现非常兴奋。虽然Google光明正大的赢了，但是核心问题还是没有解决，因为联邦法院对API版权的判决令人失望。

Java更大的问题是Oracle对这种编程语言的私有制，以及相应的管理权限的缺乏。Java在过去的一个世纪里发展缓慢(Java6和Java7之间有五年的差距)，甚至有人给拉里·埃里森写了一封请愿书，说“Java EE的发展应该被视为全球IT产业发展的重要组成部分”。因此，Java正在通过一些新的开源语言在一些中心领域逐渐获得市场份额，比如Scala。根据Indeed.com的综合数据，从2012年到2016年，与Scala开放相关的工作数量增加了500%以上，而与Java开放相关的工作数量同期减少了33%。

这种趋势最明显的早期迹象可能是数据处理发生在分布式空栈(Spark，Mesos，AKKA，Cassandra，卡夫卡)。这些平台架构都是用Scala写的。Scala用于编辑Spark，以便在正确的时间成为正确的语言——同样的Spark现在帮助推广Scala。语法，Spark和Scala几乎是同一个API，Scala就像是Spark的乘幂器。

除Scala之外，以数据为中心的应用程序和可组合并发原语的重要性日益增加，这引起了函数式编程语言Clojure、Erlang、Haskell和Haskell的广泛兴趣。

移动数据、微服务和Scala

Scala在移动数据和微服务趋势中的重要性也非常明显:在Lightbend最近对全球2151名JVM开发人员的调查中，Scala开发人员使用微服务的人数比Java多50%。在所有使用微服务的开发者中，35%使用Akka，30%使用卡夫卡，19%使用Spark。

我通过从Akka、Kafka和Spark的GitHub数据库中提取他们的每日时间序列数据来比较他们。我从三个独立的时间序列数据中观察到:新观察者的总数、拉请求和提交[办公室1]。每个数据的跨度是从13年9月30日到16年9月30日。为了便于观察，我把这些时间序列数据表放入一个平滑的2周移动平均线。本文的查询是基于GitHub上Google BigQuery SQL接口存档的开源数据。所以这里可以看到查询代码。

图1 github上Spark、Akka、Kafka每日新观察者的时间序列数据。出发地:DataScience.com。

图2:2:GitHub上Spark、Akka、卡夫卡日拉请求的时间序列数据。出发地:DataScience.com .

图3。星火、阿卡、卡夫卡日变化的时间序列数据

出发地:DataScience.com。

斯帕克和卡夫卡的发展

Spark显然是新数量的观察者和拉请求中最活跃的选项。这不应该是一个惊喜。Spark仍然是数据社区中最活跃的开源项目。从2015年到2016年，代码库的贡献者增加了67%。Scala仍然是Spark的第一种编程语言，其次是Python。

卡夫卡在拉被要求的数据方面似乎已经赶上了阿卡。值得注意的是，自从汇合接管了卡夫卡的维护，一些开发转移到了Java。同时，卡夫卡已经成为围绕流动数据的批量ETL系统的替代品。

此外，卡夫卡允许您构建分布式系统，甚至保证一次性交付。此外，您可以发送保持格式的二进制数据(例如，在Avro中)。如果想使用Scala这样的强类型语言，可以保留所有的数据形式。这显然不同于JSON转储，JSON转储要求您再次解析您的数据。(生成的JSON数据是ETL系统中样本文件的主要来源)。

似乎许多像数据科学这样的创业公司都是卡夫卡的新用户，把卡夫卡作为一个可扩展的微服务管道。汇合的思维也体现了这一点。杰伊·克雷普斯也在今年早些时候的博客中阐述了这一点。

这个博客有几个有趣的地方:

Spark每日请求数量的增加发生在每个发布日期之前的一段时间内

2016年1月，阿卡的承诺大幅增加。(2008年共承诺)。似乎有一些主要的房屋清理——修理工将Akka中的大量提交和HTTP合并到主分支。

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

dotty-新的行业标准？

马丁·奥德斯基一直在领导多蒂的工作。Dotty是基于依赖对象类型(DOT)演算(基本上是Scala的简化版本)和函数式编程(FP)数据库社区的创新研究编译器。

从事Dotty开发的团队对现有技术进行了一些重大改进，尤其是在编译时间方面。我问奥德斯基关于多蒂架构的创新以及如何帮助终端用户。他是这样说的:

有两个思路:第一，与形式基础密切相关，可以更好的指导我们如何设计一个音型系统。这会给最终用户带来更少的惊喜。二是有基本的功能架构。这样更容易扩展和修正，也会带来更强大的API，其中编译器具有服务IDE和元编程的功能。

虽然Dotty开辟了很多有趣的语言可能性(尤其是全谱依赖类型，la Agda和Idris)，但奥德斯基还是选择优先让其对社区产生立竿见影的效果。语言差异相当小，大部分都是为了简化语言(比如删除进程语法)或者修复错误(不完善的模式匹配)或者两者兼而有之(早期的初始化器)。

有趣的是，奥德斯基其实有很长的构建人们使用的编译器的历史。在他完成博士学位之前，他把一个帕斯卡编译器卖给了博兰。他后来完成了博士学位。在尼克劳斯·沃思(帕斯卡的创始人)手下，他在IBM(E语言，后来商业化)完成了一些博士后工作，然后抓住了函数式编程(FP)的错误。他继续写比萨(使用Haskell和Philip Wadler的Java泛型名气)和漏斗。当时没有人使用这些，但他和沃德勒发明了GJ编译器，这当然导致了Java的广泛使用。他还写过几个Scala编译器(多蒂是第五或者第六个)。我这里可能漏掉了什么，但重点是，他还是挺靠谱的。

但是，我不能拒绝问他，全谱依赖类型是否有可能在某个时候结束在Scala中。以下是他的回答:

“永远不要说不:-)，事实上，我们目前正在与维克多·昆卡(Viktor Kuncak)合作，将利昂程序与Scala进行集成，后者需要比我们现在更丰富的依赖类型。但目前正处于严谨的研究阶段，将会有一个完全公开的结果。”

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

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

出发地:DataScience.com

图5:5:GitHub上各编译器拉取请求(PRS)的时间序列数据。出发地:DataScience.com

图6:6:GitHub上每个编译器提交的时间序列数据。

出发地:DataScience.com

我还通过分析来自两个编译器各自GitHub的时间序列数据来比较这两个编译器(以及Typelevel的fork)。总的来说，新的观察者(可能来自Dotty文档和黑客新闻帖子)是这些时间序列数据中最有趣的东西。

Lightbend是一家支持Scala和PLAY reaction JVM框架的公司，由前扑克冠军、软件工程师保罗·菲利普斯(Paul Phillips)和Akka创作者JonasBonér创建，公司最初命名为“Typesafe”以体现其功能性编程根源，2016年2月更名为“Lightbend”。我和莱特本公司的首席执行官马克·布鲁尔谈了谈公司在Scala的工作。他是这样说的:

“Scala 2.12是Lightbend和许多外部贡献者的一项重要投资。为了利用Java 8中的功能，后端已经完全重写(因此编译成Java字节码的时候不需要把Scala转换成Java)。

此外，2.12带来了新的优化器来执行更深层次的静态分析，从而消除了函数式编程中常见的高阶代码模式的开销。现在2.12结束了(希望)(希望)，球队也开始了2.13的工作。2.13功能集仍在定义中，但它将包括一个新的收藏库(已由社区请求)和多蒂的其他功能。"

Lightbend现在在2.12版本上发布，特别展示了Scala对FP社区需求和输入的响应。

最后，有趣的是，随着Dotty越来越接近编译大部分主要Scala生态系统，在开发周期中节省大量时间的前景吸引了很多公司，并表示有兴趣尽快开发Dotty和Scala。当Dotty用scalac实现函数奇偶性时，会发生什么会比较有趣。

战争行为准则

Scala是一种多范式语言，它的社区是一种反映。马丁·奥德斯基的Scala最初的目标是证明功能代码可以按照面向对象的原则来组织。除了上面列出的大量Java转换项目外，这种设计还导致采用了从纯函数编程(FP)语言(比如Haskell)的转换。

社区细分:猫和斯卡拉兹

历史上Scala FP社区一直以Scalaz为代表，至今仍是GitHub上最著名的Scala库之一。一直以来都有大量的开发人员从Haskell被派到Scalaz自从Scalaz建立以来，社区一直倾向于将Haskell类型的FP模式和语法移植到Scala中，达到一定程度。

爱德华·克米特在这篇文章中说，2014年底，在新的行为准则(CoC)失败后，社区开始崩溃。

Typelevel人实际上创建了一个新的FP库(猫)。猫不是Scalaz的直接分支，但它使用了许多相同的概念，或多或少是Scalaz的直接竞争对手。

图7:猫和斯卡拉兹在7:GitHub上的时间序列数据。

出发地:DataScience.com

图8:猫和Scalaz的PRs在8:GitHub上的时间序列数据。

出发地:DataScience.com

图9:猫和Scalaz在9:GitHub上提交的时间序列数据。

出发地:DataScience.com

就PRs活动指标的总体规模而言，cat比Scalaz大，但其中一些指标可能是由于库的年龄造成的。然而，就每天的承诺量和每天的新观察者而言，Scalaz似乎没有显著减少。所以社区里有些人的恐惧好像已经过去了。Scalaz和Cats的存在其实给下游的库带来了很多麻烦，虽然大部分人都是通过包含FP依赖(比如FS2和scodec)，或者通过垫片或者源代码级预处理找到了可行的解决方案。

另一方面，也许托尼·莫里斯说得对，Scalaz项目和Cats在动机上有很大的差异，最终两个库都有各自的空进一步发展的空间，服务于Scala社区的不同需求。cat一直在努力保持轻量级和模块化(见此处和此处)，避免Scalaz中一些难以置信的语法。

言论自由vs .没有暴力交流

Scalaz CoC失败的最大原因是第一个被禁止引进Scalaz CoC的人是项目的创始人。然而，更大的原因可能是CoC被强加给了一个已经运作了7年的社区，而不是作为一个新事物被引入。这样改变群体话语的模式，可能相当于要求参与者加入一个完全独立的运动。两个最有可能的结果是CoC被断然拒绝，或者(Scala内部发生的)CoC被忽略，论坛活动一直被消极地拖到近乎停止。

Scalaz的剧本主要揭示了开源软件开发中行为准则上的哲学分歧(最近出现在Scala辩论论坛上)。一方认为想法是平等的，如何传达这些想法并不是很重要(今年的辩论在LambdaConf引起了争议)。另一方认为他们不能接受仅仅因为批评以粗鲁或侮辱的方式传达就忽视批评。

另一方认为暴力传播拖累了整个社区，所以可接受传播的概念应该受到CoC的限制。从我的个人经验来看，我与Typelevel人员的接触非常积极——我团队中的每个人都有同样的感受。Typelevel对使用自己项目的新人非常有耐心，尤其是使用cat工具的新人。

您是否使用Scala来消除一些FUD错误

像任何主流编程语言一样，Scala吸引了许多权威人士和“Scala很棒”和“Scala死了”的评论(显然来自一个Java开发人员)。如果你在考虑学习Scala或者聘请Scala团队，那么你必须考虑两个方面，做出自己的判断。在消除FUD的一些明显错误的同时，我想解决一些人们共同关心的问题。

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

今年2月，不太为人所知的Scala母公司Typesafe更名为Lightbend。这些顾虑对我来说显然是言过其实了。Lightbend首席执行官马克·布鲁尔(Mark Brewer)在以下博客中明确指出，Lightbend将继续为Scala及其团队工作。当我提到对布鲁尔的这种长期关注时，他说:我们很高兴Scala周围有一个非常迷人的声音，这意味着Lightbend所做的已经被广泛报道。与其没有互动，不如有用户投诉。

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

这个问题其实是有根据的。Scala的学习曲线比很多其他语言都要艰难，缺乏针对新员工(比如Rust拥有的)的集中培训资料和社区论坛是目前的问题。今年3月，洛桑瑞士联邦理工学院宣布建立一个名为Scala Center的Scala开源平台(由Lightbend、IBM、Verizon等组织支持)。

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

希望Scala Center的引入也能包含一些改进Scala文档的努力。我和斯卡拉中心的首席执行官希特尔·米勒谈过，她是这样评价这份文件的:

“对我个人来说，文档是一个长期的问题，我也认为公司需要雇佣一名技术作家来解决这个问题。对于我来说，在过去的五年里，我一直非常热衷于编辑许多开放的Scala文档，编写文档一定不是一项自愿的任务。但是由于Scala Center有管理层，所以是否拨款，聘请专业写手改进文档，并不是我说了算的。这是需要在即将召开的委员会会议上提出、讨论和表决的问题。在那之前我什么也做不了。”

斯卡拉中心现在有3.5名全职员工。该中心作为瑞士洛桑联邦理工学院的一部分，有一套非常严格的就业规定(比如员工必须是联邦学院的医院，工资不算多等。).该中心听取一些非官方渠道的意见，如个人、公司或每周委员会成员的意见。这些建议将转化为提案，每三个月提交给委员会会议。委员会成员将对这些提案进行投票，考虑投资者的关注，然后根据中心拥有的人力完成写作任务。

4.对Scala团队开发的担忧

在某种程度上，这些担忧是有根据的。除了Scalaz插曲，抱怨论坛数量下降的人数也在增加。米勒说，她也和一些人有联系，其中大多数是女性。当她谈到这件事时，这些人觉得

“这不仅仅是恐吓，有时是羞辱？他们看到人们一个个退出，他们选择不参与。他们觉得整个论坛充满了敌意，这些敌意比他们添加的其他社区更多。”

到目前为止，Scala中心的重点项目包括放松Scala/Dotty移动性和改善高层管理(他们最近重启了Scala改善项目)。该中心现在准备宣布推出一个新的Scala平台，并重建相应的数据库。

5.对雇佣Scala开发人员的担忧

这个问题是有根据的。如果您预见到需要增加一个大型团队或快速发展一个团队，Scala可能不是一个好的语言选择。与其他主流函数式语言相比，Scala开发人员的需求往往很高。

专业人员分布也很合理。大部分工作人员主要在科技中心，少数分散在全国各地。但是，除了湾区、洛杉矶、纽约、西雅图，你大概需要适应远程团队工作。经验丰富的Scala开发人员也有很好的自我价值感。虽然可以同时雇佣几个资深Scala开发人员，但是用成熟的Scala开发人员填满你的整个团队并不容易，成本也不低。这和建设Java开发团队的标准策略不同，不可能同时雇佣大量的成熟人才。

图10。出发地:DataScience.com

语言的发展

Scala是一个非常高效的团队。与此同时，我们看到了一个普遍的行业向函数式编程的转变，这给现代技术平台的其他部分带来了一些复杂性的增长，这可能是一件好事。Scala无疑被认为是分布式数据处理中的一个合适的嵌入，现在它也在主流中拉动功能技术的应用。在这方面，她从热情的函数式编程语言社区中受益匪浅。

我不认为Scala希望看到Scala“扩展到所有企业”。相反，我与之交谈的许多人都有一个共识，即Java类型的趋势是不健康的。Java占主导地位然后停滞了一个世纪，对编程来说不是什么好事。所以继续实验，争取成长，抵制早期标准化，简化语言而不是积累语言扩展才是健康的趋势。因此，清晰、可编辑、可理解的增长和迭代到可以接近但无法实现的最佳状态是Scala发展的最健康的趋势。

你可能也想看看