Go 与 Scala

我不知道有什么办法说服人放弃一种语言，用另外一种。不是由于咱们无法客观比较，而是通常人们会由于各类缘由拒绝客观比较。

我在腾讯工做的时候，咱们团队和深圳一个团队合并。我注意到深圳一位同事用Scala，写的程序相对用Java简练清晰，让人眼前一亮。我所以专门学习了一段时间Scala。于此同时，我也在学习Go。两个学习过程同时开始，没有什么偏见。可是后来开始开发Peacock（http://arxiv.org/abs/1405.4402）的时候我决定用Go，而不是Scala。缘由有二：

1. JVM程序dockerization的成本过高了：每一个docker container里得安装JVM和标准库，花掉几百MB。一台机器若是跑100个container，一个机群100台机器，一个月要为此给Google Compute Engine或者Amazon AWS多付多少钱？程序员能够不算帐，老板可不行。我在“在将来，Go语言可否撼动Java在Android、Hadoop大数据、云计算领域的地位？ - 王益的回答”里也提到这个问题。不用container技术能够吗？这能够作另一个问题讨论了。只提醒一点：Docker用的Linux kernel cgroup系统调用是2007年Google Borg的开发者贡献给Linus的，而Google Borg是Google MapReduce框架的代码量只有Hadoop的百分之一，而功能却强大得多的根本缘由。更详细的讨论请见这里：分布式机器学习的故事：Docker改变世界 - Occam's Razor - 知乎专栏。
2. Scala的并发语法（和其余不少想法）直接借鉴于functional programming languages学术研究成果，不够贴近工程须要。12年前，个人同窗王垠教了我DrScheme（如今叫作Racket了）。这是MIT开发的计算机系本科生的启蒙语言。其中有一种语法叫future，也就是Scala里支持并发的语法。Future是1972年就写进书里了《google.com 的页面》的。它要求一个并发单元最后会返回，而且要返回一个值。这个要求很符合pure functional programming（程序里除了IO不容许有side effect）的调调，可是不符合实际工程工做须要——我要起一个并发单元执行一个Web server，这事儿显然就没有什么返回值。Go的goroutine显然更务实——不须要返回什么值。那结果怎么传回来呢？用channel啊。实际上，goroutine + channel能够彻底复现future语法：只须要把一个future定义为一个返回channel的goroutine便可——代码行数都和Scala同样。请看这里的例子：http://www.golangpatterns.info/concurrency/futures。

Peacock如今已经在腾讯广告系统和其余产品里应用。它的训练系统运行在数百台机器上，一个任务里的并发单元以百万计。不少大规模并行机器学习系统的并发规模都如此甚至更大，包括Google Machine Translation背后的language model training system，以及广告点击率预估系统（请参见：Research Blog: Lessons learned developing a practical large scale machine learning system）。在这样的架构下，上述两个因素就成了决定性因素了。

回到主题。我不肯定Scala任什么时候候都比Go好用，可是上述实践让我基本明白，大规模并行系统的开发仍是用Go比较现实。虽然我看到不少朋友说JVM语言的“生态好”，可是恐怕这很快就会随着Docker、etcd、CoreOS和Kubernetes引导开源社区而变成过去式了，因此我不敢把“生态好”当作一个重要因素来验证Scala更适合开发大规模并发系统。