下载掌阅APP，畅读海量书库
立即打开
从Go语言诞生的那一刻起至今已经有十多年了，Go语言的魅力使得其在世界范围内拥有百万级的拥趸。那么究竟是什么让大量的开发人员开始学习Go语言或从其他语言转向Go语言呢？笔者认为，Go语言的魅力就来自Go语言的设计哲学。
关于Go语言的设计哲学，Go语言之父们以及Go开发团队并没有给出明确的官方说法。在这里笔者将根据自己对他们以及Go社区主流观点和代码行为的整理、分析和总结，列出4条Go语言的设计哲学。理解这些设计哲学将对读者形成Go原生编程思维、编写高质量Go代码起到积极的作用。
简单是一种伟大的美德，但我们需要更艰苦地努力才能实现它，并需要经过一个教育的过程才能去欣赏和领会它。但糟糕的是：复杂的东西似乎更有市场。
——Edsger Dijkstra，图灵奖得主
当我们问Gopher“你为什么喜欢Go语言”时，我们通常会得到很多答案，如图3-1所示。
图3-1 Gopher喜欢Go的部分原因
但在我们得到的众多答案中，排名靠前而又占据多数的总是 “简单” （Simplicity），这与官方Go语言用户调查的结果 [1] 是一致的，见图3-2。（由于2016年之后的官方Go用户调查中不再设置“你最喜欢Go的原因是什么”这一调查项，因此这里引用的是2016年Go用户调查的结果。）
图3-2 2016年Go语言用户调查结果节选
不同于那些通过相互借鉴而不断增加新特性的主流编程语言（如C++、Java等），Go的设计者们在语言设计之初就 拒绝走语言特性融合的道路 ，而选择了“做减法”，选择了“简单”，他们把复杂性留给了语言自身的设计和实现，留给了Go核心开发组自己，而将简单、易用和清晰留给了广大Gopher。因此，今天呈现在我们眼前的是这样的Go语言：
■简洁、常规的语法（不需要解析符号表），它仅有25个关键字；
■内置垃圾收集，降低开发人员内存管理的心智负担；
■没有头文件；
■显式依赖（package）；
■没有循环依赖（package）；
■常量只是数字；
■首字母大小写决定可见性；
■任何类型都可以拥有方法（没有类）；
■没有子类型继承（没有子类）；
■没有算术转换；
■接口是隐式的（无须implements声明）；
■方法就是函数；
■接口只是方法集合（没有数据）；
■方法仅按名称匹配（不是按类型）；
■没有构造函数或析构函数；
■n++和n--是语句，而不是表达式；
■没有++n和--n；
■赋值不是表达式；
■在赋值和函数调用中定义的求值顺序（无“序列点”概念）；
■没有指针算术；
■内存总是初始化为零值；
■没有类型注解语法（如C++中的const、static等）；
■没有模板/泛型；
■没有异常（exception）；
■内置字符串、切片（slice）、map类型；
■内置数组边界检查；
■内置并发支持；
……
任何设计都存在权衡与折中。Go设计者选择的“简单”体现在，站在巨人肩膀上去除或优化在以往语言中已被证明体验不好或难于驾驭的语法元素和语言机制，并提出自己的一些创新性的设计，比如首字母大小写决定可见性，内存分配初始零值，内置以go关键字实现的并发支持等）。Go设计者 推崇“最小方式”思维 ，即一件事情仅有一种方式或数量尽可能少的方式去完成，这大大减少了开发人员在选择路径方式及理解他人所选路径方式上的心智负担。
正如Go语言之父Rob Pike所说：“Go语言实际上是复杂的，但只是让大家感觉很简单。”这句话背后的深意就是“简单”选择的背后是Go语言自身实现层面的复杂性，而这种复杂性被Go语言的设计者“隐藏”起来了。比如并发是复杂的，但我们通过一个简单的关键字“go”就可以实现。这种简单其实是Go开发团队缜密设计和持续付出的结果。
此外，Go的简单哲学还体现在Go 1兼容性的提出。对于面对工程问题解决的开发人员来说，Go 1大大降低了工程层面语言版本升级所带来的消耗，让Go的工程实践变得格外简单。
Go 1定义了两件事：第一，语言的规范；第二，一组核心API的规范，即Go标准库的“标准包”。Go 1的发布包括两个编译器套件gc和gccgo，以及核心库本身。
符合Go 1规范的程序将在该规范的生命周期内得到正确编译和运行。也许在某个不确定的时间点会出现Go 2规范，但在那之前，在Go 1的未来版本（Go 1.1、Go 1.2等）下，今天能工作的Go程序仍应该继续正常工作。
兼容性体现在源码级别。版本之间无法保证已编译软件包的二进制兼容性。Go语言新版本发布后，源码需要使用新版本Go重新编译和链接。
API可能会增长，会增加新的包和功能，但不会破坏现有的Go 1代码。
从Go 1.0发布起至今，Go 1的兼容性得到很好的保障，当初使用Go 1.4编写的代码如今也可以顺利通过最新的Go 1.16版本的编译并正常运行起来。
正如前面引用的图灵奖得主Edsger Dijkstra的名言，这种创新性的简单设计并不是一开始就能得到程序员的理解的，但在真正使用Go之后，这种身处设计哲学层面的简单便延伸到Go语言编程应用的方方面面，持续影响着Go语言编程思维。
在Go演化进入关键阶段（走向Go 2）的今天，有人向Go开发团队提出过这样一个问题：Go后续演化的最大难点是什么？Go开发团队的一名核心成员回答道： “最大的难点是如何继续保持Go语言的简单。”
[1] Go语言2016年调查结果： https://blog.golang.org/survey2016-results 。
当我们有必要采用另一种方式处理数据时，我们应该有一些耦合程序的方式，就像花园里将浇水的软管通过预置的螺丝扣拧入另一段那样，这也是Unix IO采用的方式。
——Douglas McIlroy，Unix管道的发明者（1964）
C++、Java等主流面向对象（以下简称OO）语言通过庞大的自上而下的类型体系、继承、显式接口实现等机制将程序的各个部分耦合起来，但在Go语言中我们找不到经典OO的语法元素、类型体系和继承机制，或者说Go语言本质上就不属于经典OO语言范畴。针对这种情况，很多人会问：那Go语言是如何将程序的各个部分有机地耦合在一起的呢？就像上面引述的Douglas McIlroy那句话中的浇水软管那样， Go语言遵从的设计哲学也是组合。
在诠释组合之前，我们可以先来了解一下Go在语法元素设计时是如何为组合哲学的应用奠定基础的。
在语言设计层面，Go提供了正交的语法元素供后续组合使用，包括：
■Go语言无类型体系（type hierarchy），类型之间是独立的，没有子类型的概念；
■每个类型都可以有自己的方法集合，类型定义与方法实现是正交独立的；
■接口（interface）与其实现之间隐式关联；
■包（package）之间是相对独立的，没有子包的概念。
我们看到无论是包、接口还是一个个具体的类型定义（包括类型的方法集合），Go语言为我们呈现了这样一幅图景：一座座没有关联的“孤岛”，但每个岛内又都很精彩。现在摆在面前的工作就是以最适当的方式在这些孤岛之间建立关联（耦合），形成一个整体。 Go采用了组合的方式，也是唯一的方式。
Go语言提供的最为直观的组合的语法元素是类型嵌入（type embedding）。通过类型嵌入，我们可以将已经实现的功能嵌入新类型中，以快速满足新类型的功能需求。这种方式有些类似经典OO语言中的继承机制，但在原理上与其完全不同，这是一种Go设计者们精心设计的语法糖。被嵌入的类型和新类型之间没有任何关系，甚至相互完全不知道对方的存在，更没有经典OO语言中的那种父类、子类的关系以及向上、向下转型（type casting）。在通过新类型实例调用方法时，方法的匹配取决于方法名字，而不是类型。这种组合方式，笔者称之为 “垂直组合” ，即通过类型嵌入，快速让一个新类型复用其他类型已经实现的能力，实现功能的垂直扩展。
下面是一个类型嵌入的例子：
// $GOROOT/src/sync/pool.go
type poolLocal struct {
private interface{}
shared []interface{}
Mutex
pad [128]byte
}
我们在poolLocal这个结构体类型中嵌入了类型Mutex，被嵌入的Mutex类型的方法集合会被提升到外面的类型（poolLocal）中。比如，这里的poolLocal将拥有Mutex类型的Lock和Unlock方法。但在实际调用时，方法调用会被传给poolLocal中的Mutex实例。
我们在标准库中还经常看到如下的interface类型嵌入的代码：
// $GOROOT/src/io/io.go
type ReadWriter interface {
Reader
Writer
}
通过在interface的定义中嵌入interface类型来实现接口行为的聚合，组成大接口，这种方式在标准库中尤为常用，并且已经成为Go语言的一种惯用法。
interface是Go语言中真正的“魔法”，是Go语言的一个创新设计，它只是方法集合，且与实现者之间的关系是隐式的，它让程序各个部分之间的耦合降至最低，同时是连接程序各个部分的“纽带”。隐式的interface实现会不经意间满足依赖抽象、里氏替换、接口隔离等设计原则，这在其他语言中是需要很刻意的设计谋划才能实现的，但在Go interface看来，一切却是 自然而然 的。
通过interface将程序各个部分组合在一起的方法，笔者称之为“ 水平组合 ”。水平组合的模式有很多，一种常见的方法是通过接受interface类型参数的普通函数进行组合，例如下面的代码。
// $GOROOT/src/io/ioutil/ioutil.go func ReadAll(r io.Reader)([]byte, error) // $GOROOT/src/io/io.go func Copy(dst Writer, src Reader)(written int64, err error)
函数ReadAll通过io.Reader这个接口将io.Reader的实现与ReadAll所在的包以低耦合的方式水平组合在一起了。类似的水平组合模式还有wrapper、middleware等，这里就不展开了，在后面讲到interface时再详细叙述。
此外，Go语言内置的并发能力也可以通过组合的方式实现对计算能力的串联，比如通过goroutine+channel的组合实现类似Unix Pipe的能力。
综上，组合原则的应用塑造了Go程序的骨架结构。类型嵌入为类型提供垂直扩展能力，interface是水平组合的关键，它好比程序肌体上的“关节”，给予连接“关节”的两个部分各自“自由活动”的能力，而整体上又实现了某种功能。组合也让遵循简单原则的Go语言在表现力上丝毫不逊色于复杂的主流编程语言。
并发是有关结构的，而并行是有关执行的。
——Rob Pike（2012）
将时钟回拨到2007年，那时Go语言的三位设计者Rob Pike、Robert Griesemer和Ken Thompson都在Google使用C++语言编写服务端代码。当时C++标准委员会正在讨论下一个C++标准（C++0x，也就是后来的C++11标准），委员会在标准草案中继续增加大量语言特性的行为让Go的三位设计者十分不满，尤其是带有原子类型的新C++内存模型，给本已负担过重的C++类型系统又增加了额外负担。三位设计者认为C++标准委员会在思路上是短视的，因为硬件很可能在未来十年内发生重大变化，将语言与当时的硬件紧密耦合起来是十分不明智的，是没法给开发人员在编写大规模并发程序时带去太多帮助的。
多年来，处理器生产厂商一直遵循着摩尔定律，在提高时钟频率这条跑道上竞争，各行业对计算能力的需求推动了处理器处理能力的提高。CPU的功耗和节能问题成为人们越来越关注的焦点。CPU仅靠提高主频来改进性能的做法遇到了瓶颈。主频提高导致CPU的功耗和发热量剧增，反过来制约了CPU性能的进一步提高。依靠主频的提高已无法实现性能提升，人们开始把研究重点转向把多个执行内核放进一个处理器，让每个内核在较低的频率下工作来降低功耗同时提高性能。2007年处理器领域已开始进入一个全新的多核时代，处理器厂商的竞争焦点从主频转向了多核，多核设计也为摩尔定律带来新的生命力。与传统的单核CPU相比，多核CPU带来了更强的并行处理能力、更高的计算密度和更低的时钟频率，并大大减少了散热和功耗。Go的设计者敏锐地把握了CPU向多核方向发展的这一趋势，在决定不再使用C++而去创建一门新语言的时候，果断将面向多核、 原生内置并发支持 作为新语言的设计原则之一。
Go语言原生支持并发的设计哲学体现在以下几点。
（1）Go语言采用轻量级协程并发模型，使得Go应用在面向多核硬件时更具可扩展性
提到并发执行与调度，我们首先想到的就是操作系统对进程、线程的调度。操作系统调度器会将系统中的多个线程按照一定算法调度到物理CPU上运行。传统编程语言（如C、C++等）的并发实现实际上就是基于操作系统调度的，即程序负责创建线程（一般通过pthread等函数库调用实现），操作系统负责调度。这种传统支持并发的方式主要有两大不足：复杂和难于扩展。
复杂主要体现在以下方面。
■创建容易，退出难：使用C语言的开发人员都知道，创建一个线程时（比如利用pthread库）虽然参数也不少，但还可以接受。而一旦涉及线程的退出，就要考虑线程是不是分离的（detached）？是否需要父线程去通知并等待子线程退出（join）？是否需要在线程中设置取消点（cancel point）以保证进行join操作时能顺利退出？
■并发单元间通信困难，易错：多个线程之间的通信虽然有多种机制可选，但用起来相当复杂；并且一旦涉及共享内存（shared memory），就会用到各种锁（lock），死锁便成为家常便饭。
■线程栈大小（thread stack size）的设定：是直接使用默认的，还是设置得大一些或小一些呢？
难于扩展主要体现在以下方面。
■虽然线程的代价比进程小了很多，但我们依然不能大量创建线程，因为不仅每个线程占用的资源不小，操作系统调度切换线程的代价也不小。
■对于很多网络服务程序，由于不能大量创建线程，就要在少量线程里做网络的多路复用，即使用epoll/kqueue/IoCompletionPort这套机制。即便有了libevent、libev这样的第三方库的帮忙，写起这样的程序也是很不容易的，存在大量回调（callback），会给程序员带来不小的心智负担。
为了解决这些问题，Go果断放弃了传统的基于操作系统线程的并发模型，而采用了 用户层轻量级线程 或者说是 类协程（coroutine） ，Go将之称为 goroutine 。goroutine占用的资源非常少，Go运行时默认为每个goroutine分配的栈空间仅2KB。goroutine调度的切换也不用陷入（trap）操作系统内核层完成，代价很低。因此，在一个Go程序中可以创建成千上万个并发的goroutine。所有的Go代码都在goroutine中执行，哪怕是Go的运行时代码也不例外。
不过，一个Go程序对于操作系统来说只是一个 用户层程序 。操作系统的眼中只有线程，它甚至不知道goroutine的存在。goroutine的调度全靠Go自己完成，实现Go程序内goroutine之间公平地竞争CPU资源的任务就落到了Go运行时头上。而将这些goroutine按照一定算法放到CPU上执行的程序就称为 goroutine调度器（goroutine scheduler） 。关于goroutine调度的原理，我们将在后面详细说明，这里就不赘述了。
（2）Go语言为开发者提供的支持并发的语法元素和机制
我们先来看看那些设计并诞生于单核年代的编程语言（如C、C++、Java）在语法元素和机制层面是如何支持并发的。
■执行单元：线程。
■创建和销毁的方式：调用库函数或调用对象方法。
■并发线程间的通信：多基于操作系统提供的IPC机制，比如共享内存、Socket、Pipe等，当然也会使用有并发保护的全局变量。
与上述传统语言相比，Go提供了语言层面内置的并发语法元素和机制。
■执行单元：goroutine。
■创建和销毁方式：go+函数调用；函数退出即goroutine退出。
■并发goroutine的通信：通过语言内置的channel传递消息或实现同步，并通过select实现多路channel的并发控制。
对比来看，Go对并发的原生支持将大大降低开发人员在开发并发程序时的心智负担。
（3）并发原则对Go开发者在程序结构设计层面的影响
由于goroutine的开销很小（相对线程），Go官方鼓励大家使用goroutine来充分利用多核资源。但并不是有了goroutine就一定能充分利用多核资源，或者说即便使用Go也不一定能写出好的并发程序。
为此Rob Pike曾做过一次关于“并发不是并行” [1] 的主题分享，图文并茂地讲解了并发（Concurrency）和并行（Parallelism）的区别。Rob Pike认为：
■并发是有关结构的，它是一种将一个程序分解成多个小片段并且每个小片段都可以独立执行的程序设计方法；并发程序的小片段之间一般存在通信联系并且通过通信相互协作。
■并行是有关执行的，它表示同时进行一些计算任务。
以上观点的重点是，并发是一种程序结构设计的方法，它使并行成为可能。不过这依然很抽象，这里借用Rob Pike分享中的那个“搬运书问题”来重新诠释并发的含义。搬运书问题要求设计一个方案，使gopher能更快地将一堆废弃的语言手册搬到垃圾回收场烧掉。
最简单的方案莫过于图3-3所示的初始方案（以下搬书问题涉及的图片均来自 https://talks.golang.org/2012/waza.slide ）。
图3-3 搬书问题初始方案
这个方案显然不是并发设计方案，它没有对问题进行任何分解，所有事情都是由一个gopher从头到尾按顺序完成的。但即便是这样一个并非并发的方案，我们也可以将其放到多核硬件上并行执行，只是需要多建立几个gopher例程（procedure）的实例，见图3-4。
图3-4 搬书问题初始方案的并行化
但和并发方案相比，这种方案是缺乏自动扩展为并行的能力的。Rob Pike在分享中给出了两种并发方案（分别见图3-5和图3-6），也就是该问题的两种分解方案，两种方案都是正确的，只是分解的粒度大小有所不同。
图3-5 搬书问题并发方案1
图3-6 搬书问题并发方案2
并发方案1将原来单一的gopher例程执行拆分为4个执行不同任务的gopher例程，每个例程仅承担一项单一的简单任务，这些任务分别是：
■将书搬运到车上（loadBooksToCart）；
■推车到垃圾焚化地点（moveCartToIncinerator）；
■将书从车上搬下送入焚化炉（unloadBookIntoIncinerator）；
■将空车送返（returnEmptyCart）。
理论上并发方案1的处理性能能达到初始方案的4倍，并且不同gopher例程可以在不同的处理器核上并行执行，而不是像最初方案那样需要通过建立新实例才能实现并行。
和并发方案1相比，并发方案2增加了“暂存区域”，分解的粒度更细，每个部分的gopher例程各司其职。
采用并发方案设计的程序在单核处理器上也是可以正常运行的（在单核上的处理性能可能不如非并发方案），并且随着处理器核数的增多，并发方案可以自然地提高处理性能，提升吞吐量。而非并发方案在处理器核数提升后，也仅能使用其中的一个核，无法自然扩展，这一切都是程序的结构所决定的。这告诉我们： 并发程序的结构设计不要局限于在单核情况下处理能力的高低，而要以在多核情况下充分提升多核利用率、获得性能的自然提升为最终目的 。
除此之外，并发与组合的哲学是一脉相承的，并发是一个更大的组合的概念，它在程序设计层面对程序进行拆解组合，再映射到程序执行层面：goroutine各自执行特定的工作，通过channel+select将goroutine组合连接起来。并发的存在鼓励程序员在程序设计时进行独立计算的分解，而对并发的原生支持让Go语言更适应现代计算环境。
[1] https://talks.golang.org/2012/waza.slide
软件工程指引着Go语言的设计。
——Rob Pike（2012）
要想理解这条设计哲学，我们依然需要回到三位Go语言之父在设计Go语言时的初衷： 面向真实世界中Google内部大规模软件开发存在的各种问题，为这些问题提供答案。 主要的问题包括：
■程序构建慢；
■失控的依赖管理；
■开发人员使用编程语言的不同子集（比如C++支持多范式，这样有些人用OO，有些人用泛型）；
■代码可理解性差（代码可读性差、文档差等）；
■功能重复实现；
■升级更新消耗大；
■实现自动化工具难度高；
■版本问题；
■跨语言构建问题。
很多编程语言的设计者或拥趸认为这些问题并不是编程语言应该解决的，但Go语言的设计者并不这么看，他们以更高、更广阔的视角审视软件开发领域尤其是大规模软件开发过程中遇到的各种问题，并在Go语言最初设计阶段就将解决工程问题作为Go的设计原则之一去考虑Go语法、工具链与标准库的设计，这也是Go与那些偏学院派、偏研究性编程语言在设计思路上的一个重大差异。
Go语言取得阶段性成功后，这种思路开始影响后续新编程语言的设计，并且一些现有的主流编程语言也在借鉴Go的一些设计，比如越来越多的语言认可统一代码风格的优越之处，并开始提供官方统一的fmt工具（如Rust的rustfmt），又如Go创新提出的最小版本选择（Minimal Version Selection，MVS）被其他语言的包依赖工具所支持（比如Rust的cargo支持MVS）。
Go设计者将所有工程问题浓缩为一个词： scale （笔者总觉得将scale这个词翻译为任何中文词都无法传神地表达其含义，暂译为“规模”吧）。从Go1开始，Go的设计目标就是帮助开发者更容易、更高效地管理两类规模。
■生产规模：用Go构建的软件系统的并发规模，比如这类系统并发关注点的数量、处理数据的量级、同时并发与之交互的服务的数量等。
■开发规模：包括开发团队的代码库的大小，参与开发、相互协作的工程师的人数等。
Go设计者期望Go可以游刃有余地应对生产规模和开发规模变大带来的各种复杂问题。Go语言的演进方向是优化甚至消除Go语言自身面对规模化问题时应对不好的地方，比如：Go 1.9引入类型别名（type alias）以应对大型代码仓库代码重构，Go 1.11引入go module机制以解决不完善的包依赖问题等。这种设计哲学的落地让Go语言具有广泛的规模适应性：既可以被仅有5人的初创团队用于开发终端工具，也能够满足像Google这样的巨型公司大规模团队开发大规模网络服务程序的需要。
那么Go是如何解决工程领域规模化所带来的问题的呢？我们从语言、标准库和工具链三个方面来看一下。
（1）语言
语法是编程语言的用户接口，它直接影响开发人员对于一门语言的使用体验。Go语言是一门简单的语言，简单意味着可读性好，容易理解，容易上手，容易修复错误，节省开发者时间，提升开发者间的沟通效率。但作为面向工程的编程语言，光有简单的设计哲学还不够，每个语言设计细节还都要经过“工程规模化”的考验和打磨，需要在细节上进行充分的思考和讨论。
比如Rob Pike就曾谈到，Go当初之所以没有使用Python那样的代码缩进而是选择了与C语言相同的大括号来表示程序结构，是因为他们经过调查发现，虽然Python的缩进结构在构建小规模程序时的确很方便，但是当代码库变得更大的时候，缩进式的结构非常容易出错。从工程的安全性和可靠性角度考虑，Go团队最终选择了大括号代码块结构。
类似的面向工程的语言设计细节考量还有以下这些。
■重新设计编译单元和目标文件格式，实现Go源码快速构建，将大工程的构建时间缩短到接近于动态语言的交互式解释的编译时间。
■如果源文件导入了它不使用的包，则程序将无法编译。这既可以充分保证Go程序的依赖树是精确的，也可以保证在构建程序时不会编译额外的代码，从而最大限度地缩短编译时间。
■去除包的循环依赖。循环依赖会在大规模的代码中引发问题，因为它们要求编译器同时处理更大的源文件集，这会减慢增量构建速度。
■在处理依赖关系时，有时会通过允许一部分重复代码来避免引入较多依赖关系。比如：net包具有其自己的整数到十进制转换实现，以避免依赖于较大且依赖性较强的格式化io包。
■包路径是唯一的，而包名不必是唯一的。导入路径必须唯一标识要导入的包，而名称只是包的使用者对如何引用其内容的约定。包名不必是唯一的约定大大降低了开发人员给包起唯一名字的心智负担。
■故意不支持默认函数参数。因为在规模工程中，很多开发者利用默认函数参数机制向函数添加过多的参数以弥补函数API的设计缺陷，这会导致函数拥有太多的参数，降低清晰度和可读性。
■首字母大小写定义标识符可见性，这是Go的一个创新。它让开发人员通过名称即可知晓其可见性，而无须回到标识符定义的位置查找并确定其可见性，这提升了开发人员阅读代码的效率。
■在语义层面，相对于C，Go做了很多改动，提升了语言的健壮性，比如去除指针算术，去除隐式类型转换等。
■内置垃圾收集。这对于大型工程项目来说，大大降低了程序员在内存管理方面的负担，程序员使用GC感受到的好处超过了付出的成本，并且这些成本主要由语言实现者来承担。
■内置并发支持，为网络软件带来了简单性，而简单又带来了健壮，这是大型工程软件开发所需要的。
■增加类型别名，支持大规模代码库的重构。
（2）标准库
Go被称为“自带电池”（battery-included）的编程语言。“自带电池”原指购买了电子设备后，在包装盒中包含了电池，电子设备可以开箱即用，无须再单独购买电池。如果说一门编程语言“自带电池”，则说明这门语言标准库功能丰富，多数功能无须依赖第三方包或库，Go语言恰是这类编程语言。由于诞生年代较晚，且目标较为明确，Go在标准库中提供了各类高质量且性能优良的功能包，其中的net/http、crypto/xx、encoding/xx等包充分迎合了云原生时代关于API/RPC Web服务的构建需求。Go开发者可以直接基于这些包实现满足生产要求的API服务，从而减轻对第三方包或库的依赖，降低工程代码依赖管理的复杂性，也降低开发人员学习第三方库的心智负担。
仅使用标准库来构建系统，这对于开发人员是很有吸引力的。在很多关于选用何种Go Web开发框架的调查中，选择标准库的依然占大多数，这也是Go社区显著区别于其他编程语言社区的一点。Go团队还在golang.org/x路径下提供了暂未放入标准库的扩展库/补充库供广大Gopher使用，包括text、net、crypto等。这些库的质量也是非常高的，标准库中部分包也将golang.org/x下的text、net和crypto包作为依赖包放在标准库的vendor目录中。
Go语言目前在GUI、机器学习（Machine Learning）等开发领域占有的份额较低，这很可能与Go标准库没有内置这类包有关。在2017年的Go语言用户调查 [1] 中，Gopher最希望标准库增加的功能中，GUI、机器学习包就排名靠前，见图3-7。（2017年以后的Go用户调查中，该问题没有被列入调查项当中，因此这里使用了2017年的数据。）
图3-7 2017年Go语言用户调查结果节选
这或多或少反向证明了“内置电池”对于解决工程领域问题的重要性。
（3）工具链
开发人员在做工程的过程中需要使用工具。而Go语言提供了十分全面、贴心的编程语言官方工具链，涵盖了编译、编辑、依赖获取、调试、测试、文档、性能剖析等的方方面面。
■构建和运行：go build/go run
■依赖包查看与获取：go list/go get/go mod xx
■编辑辅助格式化：go fmt/gofmt
■文档查看：go doc/godoc
■单元测试/基准测试/测试覆盖率：go test
■代码静态分析：go vet
■性能剖析与跟踪结果查看：go tool pprof/go tool trace
■升级到新Go版本API的辅助工具：go tool fix
■报告Go语言bug：go bug
值得重点提及的是gofmt统一了Go语言的编码风格，在其他语言开发者还在为代码风格争论不休的时候，Go开发者可以更加专注于领域业务。同时，相同的代码风格让以往困扰开发者的代码阅读、理解和评审工作变得容易了很多，至少Go开发者再也不会有那种因代码风格的不同而产生的陌生感。
在提供丰富的工具链的同时，Go语言的语法、包依赖系统以及命名惯例的设计也让针对Go的工具更容易编写，并且Go在标准库中提供了官方的词法分析器、语法解析器和类型检查器相关包，开发者可以基于这些包快速构建并扩展Go工具链。
可以说Go构建了一个开放的工具链生态系统，它鼓励社区和开发人员为Go添加更多、更实用的工具，而更多、更实用的工具反过来又帮助Go更好地解决工程上的“规模化”问题，这是一个良性的生态循环。
简单 是Go语言贯穿语言设计和应用的主旨设计哲学。德国建筑大师路德维希·密斯·凡德罗将“少即是多”这一哲学理念应用到建筑设计当中后取得了非凡的成功，而Go语言则是这一哲学在编程语言领域为数不多的践行者。“少”绝不是目的，“多”才是其内涵。Go在语言层面的 简单 让Go收获了不逊于C++/Java等的表现力的同时，还获得了更好的可读性、更高的开发效率等在软件工程领域更为重要的元素。
“高内聚、低耦合”是软件开发领域亘古不变的管理复杂性的准则。Go在语言设计层面也将这一准则发挥到极致。Go崇尚通过 组合 的方式将正交的语法元素组织在一起来形成应用程序骨架，接口就是在这一哲学下诞生的语言精华。
不同于C、C++、Java等诞生于20世纪后段的面向单机的编程语言，Go语言是面向未来的。Go设计者对硬件发展趋势做出了敏锐且准确的判断——多核时代是未来主流趋势，于是将并发作为语言的“一等公民”，提供了内置于语言中的简单并发原语——go（goroutine）、channel和select，大幅降低了开发人员在云计算多核时代编写大规模并发网络服务程序时的心智负担。
Go生来就肩负着解决面向软件工程领域问题的使命，我们看到的开箱即用的标准库、语言自带原生工具链以及开放的工具链生态的建立都是这一使命落地的结果，Go在面向工程领域的探索也引领着编程语言未来发展的潮流。