如果對方是一個 Scala 愛好者，有什麼辦法說服他使用 Go？

01-14

跟 Scala 相比，Go 有什麼明顯的優點或者特性是 Scala 沒有的？

我不知道有什麼辦法說服人放棄一種語言，用另一種。不是因為我們沒法客觀比較，而是一般人們會因為各種原因拒絕客觀比較。

我在騰訊工作的時候，我們團隊和深圳一個團隊合併。我注意到深圳一位同事用Scala，寫的程序相對用Java簡練清晰，讓人眼前一亮。我因此專門學習了一段時間Scala。於此同時，我也在學習Go。兩個學習過程同時開始，沒有什麼偏見。但是後來開始開發Peacock（http://arxiv.org/abs/1405.4402）的時候我決定用Go，而不是Scala。原因有二：

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 - 知乎專欄。
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更適合開發大規模並發系統。

scala不是太了解，不過它宣稱的面向對象不是一個好特徵。這一點golang的做法是非常值得稱道的

呵呵，你是go的愛好者，我如何說服你用PHP？

想都別想

Update：要想知道為啥，你可以學習下Scala

快速部署，單機程序選用Golang。編程、編譯以及執行速度快，不容易反編譯。

其他情況，可以考慮用Scala

go和Scala追求的目標不一樣，兩個可以完全互換的情況比較少。

go的目標是替代c/c++做系統級編程，Scala目標是替代Java做應用級開發。

先搞清楚自己要做的事情，再去選擇合適的工具。

比如追求單機性能那就用go,

想做集群計算目前還是Scala方便，有AkkA和Spark。

目前還沒看到成熟的go集群框架。

當然騰訊比較特殊，他們C++起家，什麼東西都想往C/C++上遷，而且確實他們的計算量在那裡，把硬體用到極致是會產生很大經濟效益的，所以go是比較好的選擇。

聽說他們用C++重新實現Hadoop HDFS，不知道就具體情況，我只能說呵呵了。

有，golang的框架還很多缺失的。趕快。特別是資料庫事物攔截器(aop)之類的。發布一個可以在生產環境運行時調試的工具，像java btrace，jstack，jmap， jinfo等等。

機會真的很多。

其實這個問題有點無聊,我對語言的態度是只要有實用的地方就要了解下。比如因為要了解kafka，所以了解scala，因為要用docker，所以了解go。

回答這個問題純粹是反對 @王益的高票答案的第一條理由:JVM程序dockerization的成本太高了

jvm並不會導致dockerization成本變高,這個docker設計鏡像的時候就考慮到了。docker的鏡像是分層的,base image安裝jvm後,繼承自base image的鏡像不會因為jvm佔用額外空間。當鏡像運行後變成container,同一個image的多個container是共享文件系統的,只有container本身產生的文件才會佔用額外的空間。

給錢啊, 錢給夠了, 讓我寫彙編都行.

你不被他說服用scala就很不錯很不錯了。

上照片先。讓群眾幫你掂量掂量這事能不能成

很簡單啊，告訴他沒有JVM用就好了，這不就幾秒鐘的事么。

php是最好的語言！

scala akka比goroutine爽，類型系統比go類型系統爽，java生態比go生態好，除非對方真的深惡痛絕vm，怎麼可能說服

王益的答案我看懂的不多，可能是wangyin師兄的緣故。強烈贊同的頂多也就是JVM dockerization要多花幾百兆，然後部署到幾千台伺服器上blah,blah。我沒部署過那麼多機器，不過我想那麼大的公司可能不是太在乎那點兒差異。我不是CTO，請CTO來噴。

Future是1972年就寫進書里了《google.com 的頁面》的。它要求一個並發單元最後會返回，並且要返回一個值。這個要求很符合pure functional programming（程序里除了IO不允許有side effect）的調調，但是不符合實際工程工作需要——我要起一個並發單元執行一個Web server，這事兒顯然就沒有什麼返回值。Go的goroutine顯然更務實——不需要返回什麼值。那結果怎麼傳回來呢？用channel啊。

這真的就是那種例子，說程序員會辯護自己喜歡的語言。我覺得完全沒有道理。我雖然不那麼喜歡Go，但是我也不會倒過來說Go不好因為它非同步調用不返回值。

Hadoop沒有Mesos/Kubernetes 好，這個我是一點都不知道，我連後面這倆都沒聽過，趕緊去補一下。

還是有不少人舉出了一些我喜歡scala的例子，我是很喜歡語法糖的人，我覺得scala在很多情況下寫出的代碼可讀性要比go好。

回答題主的問題，我想作為略熟悉scala一點的我是不大可能被說服去用Go的。特別是在我讀過一個Go狂熱愛好者寫過的代碼之後。

沒Generic、沒模板這些缺點我都知道，但是Golang寫一個下午我能自信地說我了解這個語言的所有細節。你寫Scala寫個幾年也就寫個語言的子集而已。

為什麼不說服他使用rust。

go有gc 還需要runtime，還沒有類型系統。

相對來說，用go不如scala。

上面有人說，go可以做系統級編程，我就笑了。單考慮系統編程語言能準確安全控制內存這一點，go這樣的停止世界的gc能做這個？黑人問號臉。

go只是能cgo調用c而已，彙編都不行，哪來的說go的目標是替代c/c++，就不要誤導人了。

目前社區較完善的新的系統編程語言是Rust，歡迎大家試試。

為什麼要放棄一種語言？應該是讓他多學一種語言。

"聽說golang借鑒了scala，但是還是不如scala，大神你會寫go嗎，你怎麼看？" "那必須不如scala，等我學學看看..對比對比"，翻了幾頁書，"嗯？好像很不錯的樣子"。

並沒有

首先就本題來說，我覺得絕無可能。

三年後實名反對 @王益，事實證明 Golang 也沒像想像一樣發展迅速。

答案中dockerization這點我是不太同意的：Scala 本來就是 JVM 上的，有了一層 vm，幹嘛非要跟 Golang 生態圈的 docker 整合？至於說的額外開銷是必然的，docker 本來就沒有針對 JVM 做優化；但是JVM開銷怎麼說也真虛擬機要小多了吧？

並發語法問題，現在已經沒有問題，akka不比goroutine差。效率上 Golang 並不佔優勢。

另外別拿 google 熱度說事，君不見一群把 `Go` 熱度算到 `Golang` 上的統計，簡直智商下限。

附一張個人認為正確的數據

另外就是信仰問題了，讓 Scala 愛好者轉 Golang，有點像讓寫 Haskell 程序猿/博士生去寫 PHP