从 Scala 迁移到 Go，永不回头

慢部署

缓慢的编译时间和一个庞然大物会导致缓慢 CI，反过来，就导致了冗长的部署。幸运地是，聪明的工程师可以并行在不同的节点上测试，把整体上的 CI 时间从一个小时压低到 20 分钟。结果很成功，但在敏捷部署上还是存在问题。

Tooling（工具集）

IDE 支持很差。 Ensime 在多个 Scala 版本项目（在不同模块上的不同版本）上存在的问题使得导入、非 grep 型跳转到定义等的优化无法实施。这意味着所有开源和社区驱动的 IDE（例如 Vim、Emacs、Atom）都会有不太理想的特性集。这种语言似乎太复杂，而不能创建工具集！

Scala 集成也尝试进行多个项目构建，最引人注目的是 Jetbrains 的 Intellij Scala 插件，它支持跳转到定义，允许我们跳转到旧版 JAR 包，而不是已修改的文件中。我们可以使用高级语言特性查看已破坏的高亮显示。

从积极的一面来看，我们只要根据笔记本电脑的散热板的响度，就能准确地判断该程序员使用的是 IDEA 还是 sbt。但对于 MacBook Pro 用户来说，散热非常耗电，不能没有电源插座。

在全球 Scala 社区的发展（以及非 Scala 社区）

对面向对象的批评由来已久，但真正进入人们视线是在 Lawrence Krubner 发布博文之后。从那以后，选择非面向对象语言的想法开始被接受。

我们中就有好几个成员一度在学习 Haskell。

Coda Hale 发给 Scala team 的邮件“Yammer 放弃 Scala”在 2011 年引起轰动，虽然消息陈旧，但当大家观念发生转变后，就会发现 Coda Hale 说的很有道理。参考以下叙述：

“因为有些内容只有库作者需要理解，部分的复杂度已经被移除了。但是当一个库的 API 牵涉到所有的复杂度时（因为大部分的功能在调用空间中解决细节问题），工程师就需要对库运行的机制和转变成 cargo-culting 代码片段的设计模型有一个精确地认识。”

从那时起，大玩家也纷纷加入，比如 Twitter 和 LinkedIn。

以下是 Raffi Krikorian 在 Twitter 上发布内容的引用：

“与四年前不同，这次我使用 Java 作为重写的部分，而不是 Scala。 [...] 一位工程师需要花两个月的时间才能充分高效率编写 Scala 代码。“

Paul Phillips 离开 Scale 的核心团队，他在一次长谈中对它进行了讨论，并绘制了一个恼人的语言状态图 - 与我们已知的形象形成鲜明的对比。

其中恼人的原因，你可以在这个 JSON AST 辩论中找到 Scala 社区的所有先驱。 读完之后的感觉就像这样：

需要一个替代品

在“Go”进入公众视野前，似乎没有真正可以替代 Scala 的语言。看看 Coursera 博客文章“为什么我们爱 Coursera 中的 Scala？”的节选：

“我个人发现编译和加载时间是可以接受的（它没有 PHP 编辑测试循环那么紧凑，但是相比于 Scala，我们可以接受其中的类型检查和其他细节）。”

这是另一个来自同一个博客的节选：

“Scala 确实很慢。并且，动态语言要求你不断地重新运行或测试代码，直到找出所有类型错误、语法错误和 null 反向引用。 ”

易于学习

我们当中的一些人在 下班后的MOOC 上用6个月时间来学好 Scala ，而重新拾起“Go” 只要两周。实际上，我们第一次接触 Go 代码是在十个月前的一个 Code Retreat 上，那个时候我就能编写一个非常简单的 类似马里奥的游戏 了。

我们总是害怕低级语言，它们会强迫我们处理不必要的复杂层，其实这些只是在高级抽象的 Scala 中被隐藏了，例如：Futures 隐藏了 signal（信号），syscall（系统调用）和 mutexe（互斥器），不过这对于所谓的全栈开发者来说可能并不算什么事。

自古以来，当我们不确定怎么让某些东西工作的时候就会阅读 语言规范。很简单对吧，规范很好懂的！对于我这样的普通人来说意义非凡。我对 Scala（和 Java） 不满意的是看不到一个问题的完整上下文，因为它太复杂了。在看代码时，一份亲切完整的指导手册应该能在我对语言进行臆测时给我信心，并成为印证我决断正确与否的准则。