Scala 长期以来一直是 CrowdStrike 堆栈的一部分,实际上是主要语言。早在 2012 年我们就开始开发我们的应用程序时,我帮助领导了 Scala 的采用。事实上,它是我想要加入 CrowdStrike 的决策过程的优点之一。一些早期的开发人员也有兴趣采用它,因此它似乎很合适。我来自一家名为 Gravity 的公司,他们也是 Scala 的重度用户。这是那里的主要语言。我习惯了它,享受它,看到了它的力量,并认为随着 CrowdStrike 的发展,我可以防止我在 Scala 中看到的一些问题。我们在 Hadoop 上进行大规模分析和批处理作业,而我们的首席架构师(嗨,Bissel!)在 lambda 架构成为酷孩子们正在做的事情之前就在做 lambda 架构。我们一位高级工程师最近引用的一句话促使我最终写了这篇文章,描述了为什么我们将大部分堆栈转换为 Go,以及为什么新服务默认为 Go 由开发人员选择。我应该澄清 Scala 不会完全离开我们的堆栈,而不是等到这篇文章的结尾。事实上,它将补充 Go 不发光的地方。 Scala 是我们机器学习/分析堆栈的重要组成部分。它与我们使用的 Java 项目互操作,并且它能够提供我们的分析师可以使用的良好 DSL 的能力仍然使 Scala 成为一个可靠的选择。与核心开发语言相比,它变得更像是一种专门的工具。我将从技术总监的角度带您了解这一点。随着业务的增长,您需要将公司从早期的 5 名工程师扩展到 200 多名工程师。这是关于拥有一个可维护的代码库,您可以让人们轻松地跨项目并让新员工快速上手。我记得在 2009/10 年我第一次看到在 Gravity 上扩展 Scala 的潜在问题时。当我们在生产中报告了一个影响我们的大客户的重大问题时,已经接近一天结束了。我们中的几个人开始调查并能够追踪问题的根源。唯一的问题是我们一开始不知道代码在做什么。我们遇到了一个以前在我们的项目中没有见过的奇怪符号。飞船操作员 <|*|> 。有人大声说:“这是什么鬼东西?”。还有一些其他隐含的魔法正在发生,但并没有立即显现出来。使用 CMD+B 遍历该方法在我们的 IDE 中没有产生任何结果,因为它找不到符号(此后 IDE 在这里得到了改进)。快速搜索“<|*|>”也没有任何结果。我们被难住了,没有找到来源。 [1] 编写代码的开发人员在假期无法联系到,所以我们必须弄清楚。我们注意到一个名为 scalaz 的新库被包含在内,几个小时后我们找到了神秘符号并了解了发生了什么,进行了修复,生活又恢复了。那个瞬间将原本需要几分钟的修复变成了需要几个小时的修复。这就是我开始看到我们工程团队分裂的时候。
Scala 是一种强大的语言,它源于学术渊源,并提供了足够的灵活性,您可以轻松开始编写“一次编写”类型的代码。 Scala 开发人员通常走两条路:你有“它是一个更好的 java”阵营,你有“我(心脏)Applicative Functors”阵营。 “它是一个更好的 Java”阵营,就像 Scala 的简洁性一样,以及使 Scala 通常比 Java 更令人愉快的标准特性。他们的新 Scala 代码中有函数式编程,但这不是主要关注点。 “我(心脏)应用函子”阵营真正进入了他们的新功能世界,并开始在这条道路上更深入地扩展他们的知识,或者他们从像 Haskell 这样的地方带来他们已经功能的背景。根据我的经验,你开始分裂这些阵营,每个阵营都有优秀的程序员,所以你不能说一方优于另一方。在半功能方面,您可能有更多跨语言工作的通才,或者那些可能不想学习 lambda 演算理论来使用 API 服务器的人。举个例子,这是一个来自一个项目的代码示例,我们让我们的一个更高级的 Scala 开发人员开始:你们中的一些人可能会看到并说很棒,但有些人会说是 WTF 吗?上面还有数千行。这是整个团队都可以做的事情,但有一半的团队不想与它有任何关系。编写它的开发人员是一个才华横溢的人,但它把团队的一半分成了一个问题。幸运的是,这在代码审查中被发现并根据我们的内部指南被拒绝。它从未投入生产。当您扩展工程团队时,这种分裂在试图让新员工跟上进度时变得更加明显。 Scala 在获得构建环境、SBT 痛苦、IDE 环境痛苦、发布升级痛苦、缓慢的构建时间方面已经有很多粗糙的边缘,除此之外,还要增加熟练程度所需的大量功能概念,并且加速时间增长和dev 输出变慢。现在需要来自现有开发人员的更多前期培训,这也会减慢速度。 SBT 也是一个真正的痛点。总有一个人真正知道 SBT 在做什么并且可以调试每个人的问题。我知道 Scala 不是 scalaz,它们可以相互排斥,但我已经看到有或没有它的问题。这也不是 Scala “太难”的问题。我从来没有遇到过不会学习这门语言的人。这是关于投资的。你对某事进行投资,希望它以某种方式得到回报。无论是更快的上市时间、更高的性能/更低的成本,还是更高的稳定性。我见过一些特殊的地方会发生在 Scala 上,但不是在一般情况下。我们在即将扩大规模时进行了讨论,如果我们想投资更多的文档、指南、示例项目等……但现实是,我们认为与 Go 相比,投资不会回来。
这不是我工作过的公司所独有的。 Twitter 也经历了同样的成长过程,我在会议上谈过的其他公司以及我认识的使用 Scala 工作的人也经历了同样的成长过程。事实上,这是一个共同的主题。虽然您可以使用 Scala 拥有非常高绩效的小团队,但尝试发展和超过 50 人的工程组织是一场艰苦的战斗。如果您已经对 JVM 进行了投资,那么 Java8 是一个可靠的选择,它借用了 Scala 的一些概念来使 Java 更易于使用。前 Twitter 平台副总裁听说 Java8 可能是更好的选择,如果可用,他们出于类似原因选择了 Scala https://www.quora.com/Is-Twitter-getting-rid-of-Scala 你也可以看到Twitter 上的一个趋势是,最新发布的 OSS 项目使用 Java(Heron、DistributedLog 等)。事实上,Hero 版本中的一句话是:“它是用行业标准语言(Java/C++/Python)编写的,用于效率、可维护性和更容易的社区采用。”这就是 Go 出现的地方。 Go 存在的原因之一是让开发人员更有效率,限制你做某事的方式数量,并在编译器级别对世界有一个非常固执的看法。我在内部推迟了 Go 的采用。我更担心分裂,因为我们已经有很多技术在起作用,所以有另一种语言供人们学习。如果出现生产问题,我们有一项关于在凌晨 3 点至少有 3 人愿意支持新技术时考虑采用新技术的内部政策。经过多次努力(感谢 Sean Berry)并超过 3 个数字,我深入了解 Go 世界,发现它解决了我在组织扩展级别使用 Scala 遇到的许多问题。快速构建时间、小二进制文件、一个文件、内置格式、出色的工具、内置测试框架、竞争检测器、可视化分析器、一个不错的并发模型?哇,卖了!我们用 Go 做了一个成功的示例项目,然后又一个又一个,扩大了我们在 Go 上的开发人员数量,它开始成为人们想要编写的首选语言。你可以跳入任何 Go 项目并立即知道它在做什么。我是否错过了不可变类型和 Scala 的一些重要特性?当然可以,但我认为故事的可维护性方面太棒了,Go 不容忽视。我们已经看到更快的交付时间、更好的稳定性和更好的测试覆盖率。 Go 的其他好处之一是扩大了我们可以雇用的背景范围。我们可以招募任何语言背景的人,并让他们在几周内开始使用 Go。在 Scala 方面,有 JVM 学习曲线、容器的 Java 世界、JVM 调优的黑魔法、分析工具等......跨多个部门的高规模)。现在我们的大部分服务都是用 Go 编写的,最后一个迁移到 Go 的人刚刚写了他的第一个项目,然后对我说:“哇,我读过一次那个库,我确切地知道它在做什么,我已经阅读了该库的 Scala 版本四次,但我仍然不知道它有什么作用,我明白你们为什么这么喜欢它”。那是我们的一位高级工程师,他之前曾在世界上最大的网络资产之一工作。这个过程是我们开发团队的一个完整的自下而上的倡议,他们推动了向 Go 的转变。
现在,我们使用 GoLang 服务每秒处理数十万条消息和每天 TB 级的数据。有些人试图将 Go 的简单等同于弱点,但我看到了相反的情况。你可以在 Go 中做一些非常强大的东西。简单中有力量。错误处理虽然起初看起来很烦人,但实际上已经导致应用程序代码中更健壮的错误处理和稳定性。你不能只是扔东西,然后希望它在某个地方被抓住。谷歌也是一个主要投资者,拥有这种技术一致性可以访问我们可以利用的额外资源。我不是在这里抨击 Scala 或 ScalaZ(我喜欢 ValidationNel!),而是更多地在与两家公司合作 7 年多的生产环境中提供 Scala 的一些真实世界背景。我仍然使用 Scala 并且喜欢在 Scalding 中进行黑客攻击。我们即将推出的一些更雄心勃勃的项目很可能是基于 Scala 的,但在尝试扩大快速增长的工程团队的规模时,我不再像核心语言那样热衷于它。总有例外,如果你的团队真的喜欢 Scala,你可以让它发挥作用,有些公司是。 Go 位于一个经常发生的地方……当您需要小型、高性能的服务时。您在何处进行轻量级转换、整理数据并将 API 置于数据或支持系统之前。如果您有兴趣了解更多信息或聊天,请在 Twitter 上关注我 https://twitter.com/jimplush ** Marius,Twitter Scala 大师之一,似乎也对 Go 感兴趣。 [1] Code Reviews 可以解决这个问题,因为其他人会偶然发现该符号并要求更清晰和理解。这将有助于将图书馆介绍给团队,而不是一个惊喜。不幸的是,在 Gravity,我们没有要求进行代码审查。我们确实在 CrowdStrike 进行了代码审查。但是,鉴于并非每个人都参与每次代码审查,因此无法保证。