Jim Plush是網路安全服務提供商CrowdStrike的雲工程高階總監。CrowdStrike由McAffee的前CTO George Kurtz及前副總裁Dimitri Alperovitch於2011年建立。

Scala是CrowdStrike內部使用的主要語言。2011年，Jim主導了Scala的使用。在加入CrowdStrike之前，Jim就職的Gravity公司也是Scala重度使用者。前段時間，他們將技術棧從Scala轉向了Go。

Jim Plush從技術總監的角度介紹了這種變化。隨著業務增長，公司的工程師從5個增長到200多個。需要考慮的是，如何讓code base便於維護，工程師可以輕鬆跨專案交流，新人能夠快速上手。

幾年前，Jim曾遇到一個問題。當時產品中出現了一個會影響大量客戶的嚴重問題。於是他們開始研究問題所在，跟蹤程式碼的修改記錄。後來發現了一個從未見過的符號： <|*|>。當時就有人大喊：“這TMD什麼玩意兒？” 想跟進這個方法，也沒有成功。Google也搜不到什麼。

相關的開發人員正好在外度假。如果有code review機制，或許能避免此類問題，可惜當時沒有。後來大家發現，專案中引入了一個叫 scalaz 的庫。終於在這個庫中找到了那個神奇的符號，問題得以解決。

Scala是一門強大的語言，有學術背景，而且非常靈活。通常可以將Scala開發者分為兩類，一類是將Scala看作更好的Java，喜愛Scala的簡潔；一類是偏愛函數語言程式設計，願意深入挖掘，或者把在Haskell之類函式式語言上積累的經驗帶了過來。

有些程式碼用函式式風格寫出來可能非常簡潔。但是隨著團隊規模不斷擴大，如果有很多人讀不懂，問題就會凸顯。新人也很難直接上手。

Scala也有一些不夠完善的地方，像sbt、IDE有些痛點，另外還存在構建緩慢，JAR檔案較大等問題。

這種問題並不鮮見，Twitter等公司也經歷過同樣的擴張之痛。如果是小團隊，使用Scala可能非常高效；但在工程團隊超過50人之後，使用Scala會面對很大的挑戰。

而Go語言誕生的目標之一就是讓開發更高效，限制了可選的表達方式，而且在編譯層面施加了很多限制。

是否選擇Go，公司內部也有很多爭論。關於是否採用某個新技術，CrowdStrike有一個策略：如果產品出了問題，至少有3個人願意在凌晨3點提供支援

從一個示例專案入手，取得成功。後來一個又一個的專案採用了Go，這方面的開發者也越來越多。開發人員可以跳到任何一個專案，並立即知道其作用。可維護性方面的好處就不用提了。

另外，這也擴大了招聘池。可以選擇有其他任何語言背景的人，培訓幾周Go，很快就能上手。招聘Scala開發者則要困難很多。

有個不願意切換到Go的同事，在用Go寫了第一個專案之後，感慨不已：Go語言的庫，讀了一遍就知道是幹什麼的了，而Scala的版本讀了四遍，還感覺迷迷糊糊。

當然，Jim也提到，他並不是苛責Scala，有些雄心勃勃的新專案還是會用Scala編寫；但如果工程團隊不斷擴張，則不會再將Scala用作核心語言。而且，Scala並沒有完全從CrowdStrike的技術棧中移除。一些Go不太擅長的領域，Scala還是不錯的補充，比如機器學習和分析方面，需要與Java專案互操作的地方。另外，提供不錯的DSL供分析師使用，這方面Scala也是不二之選。總體而言，Scala更多變成了一種專用工具，不再是核心開發語言。

當然，關於程式語言的話題總是能引起很多爭論。Hacker News上就有很多討論。有人認為，不要把差勁程式設計師的問題歸到語言上。Scala程式碼寫不好的人，未必能寫好Go程式碼。也有人認為應該加強code review，不能讓開發人員隨意引入第三方庫。應該參考一些Scala最佳實踐，比如：https://github.com/alexandru/scala-best-practices。更多討論，可以點選“檢視原文”。

Kevin Scott(SVP Eng & Ops @ LinkedIn)在Quora上回答“Is LinkedIn getting rid of Scala?”這個問題時，也提到LinkedIn在下一代的基礎架構中，會減少對Scala的依賴，而是以Java 8、C++和Python等語言為主。

像Apache Storm，是以Clojure實現的。2.0版本則有可能基於阿里巴巴用Java實現的JStorm。後來Twitter內部開發的Storm替代產品Heron，則選擇了Java，部分效能要求較高的程式碼選擇了C++。

在團隊規模不斷擴大，招人困難的情況下，選擇簡單、易上手的語言，可能是最現實的選擇。