既然我们谈及了很多C 和 C++ 中依赖关系处理细节，让我们看看 Go 语言是如何处理的吧。在语义和语法上，依赖处理是由语言定义的。它们是明确的、清晰的、且“能被计算的”，就是说，应该很容易被编写工具分析。
在包封装（下节的主题）之后，每个源码文件都或有至少一个引入语句，包括 import 关键词和一个用来明确当前（只是当前）文件引入包的字符串：
1 | import "encoding/json" |
使 Go 语言规整的第一步就是：睿智的依赖处理，在编译阶段，语言将未被使用的依赖视为错误（并非警告，是错误）。如果源码文件引入一个包却没有使用它，程序将无法完成编译。这将保证 Go 程序的依赖关系是明确的，没有任何多余的边际。另一方面，它可以保证编译过程不会包含无用代码，降低编译消耗的时间。
第二步则是由编译器实现的，它将通过深入依赖关系确保编译效率。设想一个含有三个包的 Go 程序，其依赖关系如下：
这就意味着，A 包对 C 包的调用是由对 B 包的调用间接实现的;也就是说，在 A 包的代码中，不存在 C 包的标识符。例如，C 包中有一个类型定义，它是 B 包中的某个为 A 包调用的结构体中的字段类型，但其本身并未被 A 包调用。具一个更实际的例子，设想一下，A 包引用了一个 格式化 I/O 包 B，B 包则引用了 C 包提供的缓冲 I/O 实现，A 包本身并没有声明缓冲 I/O。
要编译这个程序，首先 C 被编译，被依赖的包必须在依赖于它们的包之前被编译。之后 B 包被编译;最后 A 包被编译，然后程序将被连接。
当 A 包编译完成之后，编译器将读取 B 包的目标文件，而不是代码。此目标文件包含编译器处理 A 包代码中
1 | import "B" |
语句所需的所有类型信息。这些信息也包含着 B 包在编译是所需的 C 包的信息。换句话说，当 B 包被编译时，生成的目标文件包含了所有 B 包公共接口所需的全部依赖的类型信息。
这种设计拥有很重要的意义，当编译器处理 import 语句时，它将打开一个文件——该语句所明确的对象文件。当然，这不由的让人想起 Plan 9 C （非 ANSI C）对依赖管理方法，但不同的是，当 Go 代码文件被编译完成时，编译器将写入头文件。同 Plan 9 C 相比，这个过程将更自动化、更高效，因为：在处理 import 时读取的数据只是“输出”数据，而非程序代码。这对编译效率的影响是巨大的，而且，即便代码增长，程序依然规整如故。处理依赖树并对之编译的时间相较于 C 和 C++ 的“引入被引用文件”的模型将极大的减少。
值得一提的是，这个依赖管理的通用方法并不是原始的；这些思维要追溯到1970年代的像Modula-2和Ada语言。在C语言家族里，Java就包含这一方法的元素。
为了使编译更加高效，对象文件以导出数据作为它的首要步骤，这样编译器一旦到达文件的末尾就可以停止读取。这种依赖管理方法是为什么Go编译比C或C++编译更快的最大原因。另一个因素是Go语言把导出数据放在对象文件中；而一些语言要求程序员编写或让编译器生成包含这一信息的另一个文件。这相当于两次打开文件。在Go语言中导入一个程序包只需要打开一次文件。并且，单一文件方法意味着导出数据（或在C/C++的头文件）相对于对象文件永远不会过时。
为了准确起见，我们对Google中用Go编写的某大型程序的编译进行了测算，将源代码的展开情况同前文中对C++的分析做一对比。结果发现是40倍，要比C++好50倍（同样也要比C++简单因而处理速度也快），但是这仍然比我们预期的要大。原因有两点。第一，我们发现了一个bug：Go编译器在export部分产生了大量的无用数据。第二，export数据采用了一种比较冗长的编码方式，还有改善的余地。我们正计划解决这些问题。
然而，仅需作50分之1的事情就把原来的Build时间从分钟级的变为秒级的，将咖啡时间转化为交互式build。
Go的依赖图还有另外一个特性，就是它不包含循环。Go语言定义了不允许其依赖图中有循环性的包含关系，编译器和链接器都会对此进行检查以确保不存在循环依赖。虽然循环依赖偶尔也有用，但它在大规模程序中会引入巨大的问题。循环依赖要求编译器同时处理大量源文件，从而会减慢增量式build的速度。更重要的是，如果允许循环依赖，我们的经验告诉我们，这种依赖最后会形成大片互相纠缠不清的源代码树，从而让树中各部分也变得很大，难以进行独立管理，最后二进制文件会膨胀，使得软件开发中的初始化、测试、重构、发布以及其它一些任务变得过于复杂。
不支持循环import偶尔会让人感到苦恼，但却能让依赖树保持清晰明了，对package的清晰划分也提了个更高的要求。就象Go中其它许多设计决策一样，这会迫使程序员早早地就对一些大规模程序里的问题提前进行思考（在这种情况下，指的是package的边界），而这些问题一旦留给以后解决往往就会永远得不到满意的解决。 在标准库的设计中，大量精力花在了控制依赖关系上了。为了使用一个函数，把所需的那一小段代码拷贝过来要比拉进来一个比较大的库强（如果出现新的核心依赖的话，系统build里的一个test会报告问题）。在依赖关系方面保持良好状况要比代码重用重要。在实践中有这样一个例子，底层的网络package里有自己的整数到小数的转换程序，就是为了避免对较大的、依赖关系复杂的格式化I/O package的依赖。还有另外一个例子，字符串转换package的strconv拥有一个对‘可打印’字符的进行定义的private实现，而不是将整个大哥的Unicode字符类表格拖进去， strconv里的Unicode标准是通过package的test进行验证的。
Go 的包系统设计结合了一些库、命名控件和模块的特性。
每个 Go 的代码文件，例如“encoding/json/json.go”，都以包声明开始，如同：
1 | package json |
“json” 就是“包名称”，一个简单的识别符号。通常包名称都比较精炼。
要使用包，使用 import 声明引入代码，并以 包路径 区分。“路径”的意义并未在语言中指定，而是约定为以/分割的代码包目录路径，如下：
1 | import "encoding/json" |
后面用包名称（有别于路径）则用来限定引入自代码文件中包的条目。
1 | var dec = json.NewDecoder(reader) |
这种设计非常清晰，从语法（Namevs.pkg.Name）上就能识别一个名字是否属于某个包（在此之后）。
在我们的示例中，包的路径是“encoding/json”而包的名称是 json。标准资源库以外，通常约定以项目或公司名作为命名控件的根：
1 | import "google/base/go/log |
确认包路径的唯一性非常重要，而对包名称则不必强求。包必须通过唯一的路径引入，而包名称则为引用者调用内容方式的一个约定。包名称不必唯一，可以通过引入语句重命名识别符。下面有两个自称为“package log”的包，如果要在单个源码文件中引入，需要在引入时重命名一个。
1 2 | import "log" // Standard package import googlelog "google/base/go/log" // Google-specific package |
每个公司都可能有自己的 log 包，不必要特别命名。恰恰相反：Go 的风格建议包名称保持简短和清晰，且不必担心冲突。
另一个例子：在 Google 代码库中有很多server 库。
Go的包管理系统的一个重要特性是包路径，通常是一个字符串，通过识别 网站资源的URL 可以增加远程存储库。
下面就是如何使用储存在 GitHub 上的包。go get 命令使用 go 编译工具获取资源并安装。一旦安装完毕，就可以如同其它包一样引用它。
1 2 3 4 5 | $ go get github.com/4ad/doozer // Shell command to fetch package import "github.com/4ad/doozer" // Doozer client's import statement var client doozer.Conn // Client's use of package |
这是值得注意的，go get 命令递归下载依赖，此特性得以实现的原因就是依赖关系的明确性。另外，由于引入路径的命名空间依赖于 URL，使得 Go 相较于其它语言，在包命名上更加分散和易于扩展。
语法就是编程语言的用户界面。虽然对于一门编程语言来说更重要的是语意，并且语法对于语意的影响也是有限的，但是语法决定了编程语言的可读性和明确性。同时，语法对于编程语言相关工具的编写至关重要：如果编程语言难以解析，那么自动化工具也将难以编写。
Go语言因此在设计阶段就为语言的明确性和相关工具的编写做了考虑，设计了一套简洁的语法。与C语言家族的其他几个成员相比，Go语言的词法更为精炼，仅25个关键字（C99为37个；C++11为84个；并且数量还在持续增加）。更为重要的是，Go语言的词法是规范的，因此也是易于解析的（应该说绝大部分是规范的；也存在一些我们本应修正却没有能够及时发现的怪异词法）。与C、Java特别是C++等语言不同，Go语言可以在没有类型信息或者符号表的情况下被解析，并且没有类型相关的上下文信息。Go语言的词法是易于推论的，降低了相关工具编写的难度。
Go 语法不同于 C 的一个细节是，它的变量声明语法相较于 C 语言，更接近 Pascal 语言。声明的变量名称在类型之前，而有更多的关键词很：
1 2 | var fn func([]int) int type T struct { a, b int } |
相较于 C 语言
1 2 | int (*fn)(int[]); struct T { int a, b; } |
无论是对人还是对计算机，通过关键词进行变量声明将更容易被识别。而通过类型语法而非 C 的表达式语法对词法分析有一个显著的影响：它增加了语法，但消除了歧义。不过，还有一个：你可以丢掉 var 关键词，而只在表达式用使用变量的类型。两种变量声明是等价的;只是第二个更简短且共通用:
1 2 | var buf *bytes.Buffer = bytes.NewBuffer(x) // 精确 buf := bytes.NewBuffer(x) // 衍生 |
golang.org/s/decl-syntax 是一篇更详细讲解 Go 语言声明语句以及为什么同 C 如此不同的文章。
函数声明语法对于简单函数非常直接。这里有一个 Abs 函数的声明示例,它接受一个类型为 T 的变量 x，并返回一个64位浮点值：
1 | func Abs(x T) float64 |
一个方法只是一个拥有特殊参数的函数，而它的 接收器（receiver）则可以使用标准的“点”符号传递给函数。方法的声明语法将接收器放在函数名称之前的括号里。下面是一个与之前相同的函数，但它是 T 类型的一个方法：
1 | func (x T) Abs() float64 |
下面则是拥有 T 类型参数的一个变量（闭包）；Go 语言拥有第一类函数和闭包功能：
1 | negAbs := func(x T) float64 { return -Abs(x) } |
最后，在 Go 语言中，函数可以返回多个值。通用的方法是成对返回函数结果和错误值，例如：
1 2 3 4 | func ReadByte() (c byte, err error) c, err := ReadByte() if err != nil { ... } |
我们过会儿再说错误。
Go语言缺少的一个特性是它不支持缺省参数。这是它故意简化的。经验告诉我们缺省参数太容易通过添加更多的参数来给API设计缺陷打补丁，进而导致太多使程序难以理清深圳费解的交互参数。默认参数的缺失要求更多的函数或方法被定义，因为一个函数不能控制整个接口，但这使得一个API更清晰易懂。哪些函数也都需要独立的名字， 使程序更清楚存在哪些组合，同时也鼓励更多地考虑命名–一个有关清晰性和可读性的关键因素。一个默认参数缺失的缓解因素是Go语言为可变参数函数提供易用和类型安全支持的特性。
评论