从Go语言的设计原则分析其适用性

这篇由Rob Pike（Go语言之父）撰写的文章Go at Google: Language Design in the Service of Software Engineering详细的介绍了Golang的设计原则，也是我进行分析的主要依据。

文章的标题其实就给我们透露了2个重要信息：Go at Google 和 Software Engineering。先看第一个，Rob在概要和第3段描述了Google在系统开发过程中面临的主要问题：软硬件规模庞大，数据量大，系统众多且复杂，使用多种语言，编译构建缓慢等。文中用了多个big去描述这些问题，并且在开篇就明确的表示：

Go is a programming language designed by Google to help solve Google's problems

Go语言是为google解决自己的问题而设计开发的。言下之意我们Google用着顺手就行了，你用的爽不爽和我无关。可能Rob他们并没有预料到Golang开源后的火热，所以设计初衷是解决公司内部问题，并不想重复发明一个大而全的万能语言。

The goals of the Go project were to eliminate the slowness and clumsiness of software development at Google, and thereby to make the process more productive and scalable.

此处进一步说明，设计目标是消除慢速和笨拙，提高效率。

第4段对痛点的描述说明了Go语言是为解决软件工程问题而生的，而不是为了处理单个的，特殊的业务特性。这些痛点无一不是软件工程的范畴：

slow builds
uncontrolled dependencies
each programmer using a different subset of the language
poor program understanding (code hard to read, poorly documented, and so on)
duplication of effort
cost of updates
version skew
difficulty of writing automatic tools
cross-language builds

其实通过Rob在文章开头这些提纲要领的解释，我们对Golang基本的设计原则已经可见一斑。那就是不应该站在语法语义的层面去看待它，而是应该从更高层的软件工程层面去理解它。

在第6段，Rob又一次对Go的设计做了三点具体要求：

* It must work at scale, for large programs with large numbers of dependencies, with large teams of programmers working on them. （适合大规模开发）
* It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.（必须是类C风格，因为Google的开发人员大量的拥有C背景。看到没？人家就是为自己公司设计的，以降低员工的学习成本）
* It must be modern. C, C++, and to some extent Java are quite old, designed before the advent of multicore machines, networking, and web application development. There are features of the modern world that are better met by newer approaches, such as built-in concurrency.（类C但不能是C，要时尚、现代化。并发的特性被在此处被强调）

第7段用了大量篇幅解释了包引用和依赖的设计，速度和简洁性是设计上考虑的关键。我个人也非常赞同强制性的不容许循环引用的设计，这会让调用链清晰简洁，也变相的要求开发人员尽早的对代码的职责划分进行完善的思考。

第10段解释语法设计，

By design, it should feel familiar to programmers accustomed to languages in the C family.

此处再次强调刻意的C风格化的原因。语法设计的总原则就是简化。但我个人不认为字数上的简化能提升多少开发速度，如function变func、format变fmt；反而是该简化的地方没有简化，比如type T struct，type关键字毫无意义。命名空间和语义也依然是遵从简化的设计，不再赘述。

13段重点介绍了并发的设计，这也是Golang最引以为豪的特性之一。

Concurrency is important to the modern computing environment with its multicore machines running web servers with multiple clients, what might be called the typical Google program. This kind of software is not especially well served by C++ or Java, which lack sufficient concurrency support at the language level.

在强调并发特性对现代计算环境的重要性的同时，批判了C++和Java在语言层面对并发的支持不够。老实说这个所谓语言层面我没太理解，看懂的老司机给解读一下。CSP模式下的并发设计高效而简洁，降低了开发者的学习和使用难度。Java里多种同步方法、各种Lock、并发调度等一系列复杂的功能在Golang里都不存在，只靠goroutine和channel去处理并发。

第15段，组合而不是继承。

This means there is no type hierarchy. This was an intentional design choice. Although type hierarchies have been used to build much successful software, it is our opinion that the model has been overused and that it is worth taking a step back.

在OO的支持上Golang做了减法。首先，对接口的实现无需显示声明我认为是非常明智的设计，我曾经在Java项目里被接口设计变动而导致大量代码改动深受其害。另一方面，我也同意组合在大部分情况下可以完全替代继承，尽管在类型层次上不算清晰，但无伤大雅。从软件工程角度讲，组合而非继承也解决了早期的过度设计，组合的方式会把代码重构的成本降到最低。想必有经验的读者看到这里已经有所感触了，理解了设计者的用心良苦。

但是，令人不敢苟同的一点是，强类型语言，不支持泛型，这2个特点结合起来写起代码真是各种酸爽的不要不要的。大量的重复、被迫overload的函数，由此产生了Golang在类型转换上的硬伤。加之其简陋而繁琐的反射机制，更是雪上加霜。貌似Golang团队已经松口未来会考虑加入泛型，拭目以待吧。

第16段Error的设计无伤大雅，

There is no question the resulting code can be longer, but the clarity and simplicity of such code offsets its verbosity.

Rob也承认了代码会冗长，但清晰。我个人认为他们对Java里的trycatch还停留在早期版本的理解上，8以后的版本，哪怕是语法糖，代码的简洁性和优雅性都远远好于Golang中满篇的error check。

第17段，Golang里的tool确实要赞一个，强大而完善。gofmt的出现避免了使用tab还是空格的冲突。美剧《硅谷》里的Richard一定不是在用Go开发他的Pied Piper，否则也不会因为这个和他的女友分手了。