什麼東西在Go裡用著開心而在其他語言裡卻很難？

谷歌的首席技術宣講師麥克•瓊斯Michael Jones如是回覆Go論壇上的一個提問:什麼東西在Go裡用著開心而在其他語言裡卻很難？。此文得到了Go的核心開發者之一的Russ Cox的推薦。我也認為它是對Go的特性的一個熱情但不失客觀地總結，特翻譯如下，以資參考。

---

“你是你能力所及”的物件模型使很多事情變簡單了，雖然最初未必能夠體會到。

介面的機制很了不起，同時也很微妙。我認為還沒有人充分利用到它絕大部分的能力。

併發模型和執行體使很多事情變簡單了、變高效了，雖然最初未必能夠體會到。

“頭等函式”的定位使很多事情簡單了、高效了，雖然最初未必能夠體會到，至少對非LISP／Scheme／T等等的開發者仍是如此。

將語言用作巨集語言的設施，對一種非LISP／J／Forth的語言是很強的。這一方面歸於語言本身，一方面得益於標準庫，但遊刃於兩者使一些事情簡單得很自然，例如解析原始碼，得出標準又美觀的版本但仍保持註釋不變，重寫現有程式碼以跟上語言和庫設計的變化（大多是指1.0版前，但其能力仍存於go vet），查遍整個現有程式碼，以便引入新的或者改動舊介面，等等。

和Web相關的庫設施，使其成為應用層級的語言，能簡單地架構複雜的面對客戶端的服務。

“實業觀”而不是“學業觀”的哲學定位，用在諸如建造管理、設計針對測試、測試融於開發上，這些對大型軟體團隊很普通，但卻通常是新語言所缺失的。

一貫地簡潔使編碼、測試、除錯、（和將來時態的）長期維護變容易了，雖然人們最初未必能夠體會。例如，事情就是它們看起來的樣子，做著看樣子它們在做的事情。像這樣的工具（C，Go，錘子，砧板，螺絲起子等等），是人們很容易喜歡上的。

開發、編譯和執行是三倍的速度，這相當地獨特，也恰當地揭示了它的前途：成品程式碼用在龐大的系統上、勝任出奇豐富的業務，並且能快樂程式設計、輕鬆理解、和迅速執行。要記得效能自身也是一種賦能的科技。

它看著還“小”，仍能輕易地適合一個人的心智模式，正如‘C’。這是優點。

Map作為頭等原語有些意思。人們總能把關聯儲存做成個附加，但頭等對待並加以整合可以降低使用門檻。這有助於輕鬆達致更好的O(n)方式，並巧妙地將開發者帶向高效能的設計，並在問題面擴大後仍能維持快捷。

對一個新語言而言，它的庫是不尋常地精密。閱讀API文件可以看出上述的元素（特別是介面），是如何美妙地用一種新穎的方式重組服務。直到庫的設計對你而言是自然而然之前（“啊，對呀。我也會這樣做），你還不能算個地道的Go者。它有些“相當”雅緻的元素，會一直保持典雅，就在這時代大部分的語言都褪色的時候。

Michael Jones
Aug 9, 11:58 am
Re: [go-nuts] Fun things in Go that are hard in other languages?

The "you are what you can do" object model makes many things simple, in ways perhaps not appreciated at first. The Interface mechanism is simultaneously extraordinary and subtle. For the most part I think none of us yet fully realize its power.

The concurrency model and runtime make many things simple and efficient, in ways perhaps not appreciated at first.

The "first-class functions" orientation makes many things simple and efficient, in ways perhaps not appreciated still, at least by non-Lisp/Scheme/T/etc. developers.

The language-as-metalanguage facilities are strong for non-Lisp/non-J/non-Forth languages. This is partially the language, and partially the standard libraries, but between them they make it easy and natural to do such things as parse source and emit standardized pretty-printed versions with comments intact, rewrite code bases to match evolving language features and library designs (mostly pre-1.0 but the power remains in go vet), check the entirety of the codebase for possible introduction of new or change of old interfaces, etc.

The web-related library facilities makes it an application-level language for simple construction of sophisticated client-facing services.

A philosophical orientation from the "industrial view" rather then the "academic view" on issues like build management, design for test, test in development, and so on that is maybe common in large software teams but heretofore absent in new-language efforts.

The consistent simplicity makes coding, testing, debugging, (and future tense) long-term maintenance easy in ways perhaps not appreciated at first. For example, things mean what they seem to mean and do what they seem to do. Tools like this (C, Go, the hammer, the anvil, the screwdriver, etc.) are easy to love.

The speed of development, compilation, and execution are as a triple, rather unique and a good suggestion of what may lie ahead: production code on very large systems capable of marvelously rich services that is fun to write, easy to undersand, and speedy in execution performance. Remember that performance itself is an enabling technology.

It still seems "small" and can fit in one's mental model easily, just as C. This is goodness.

Integration of Maps as a first-class primitive is interesting. One could always build associative storage systems as an add-on, but being first class and integrated lowers the usage barrier. This can help make the "easy way" the better O(n) way and subtly lead developers to performant designs that stay fast as problem size scales up.

The library is unusually sophisticated for a new language. Read the API documentation to see how wonderfully the elements above (Interfaces especially) are used to factor services in new and novel ways. Until the design of the library is natural to you ("oh, of course, that's how I would have done it too") then you're not yet a Go native. There are VERY elegant elements in there that will still be elegant when most contemporary languages are gone.

Some thoughts, Michael

-- Michael T. Jones | Chief Technology Advocate | m...@google.com | +1 650-335-5765