开放式编程语言错误如何解决

不良的编程习惯TOP1：粘贴复制 在学生时代，我们都知道抄袭是不对的。但在工作中，这方面的规则还很模糊。虽然有些代码块是不能盗用的——不要把专有代码拷贝到你的堆栈中，尤其是这些代码有标记版权信息。这种时候你应该编写自己的版本，老板付你薪水就是要做正事的。 但是当原始创作者想要共享代码时，问题就变得复杂了。这些共享代码也许放到了某个在线编程论坛上，也许它们是带有许可证（BSD，MIT）的开放源代码，允许使用一到三个函数。你使用这些共享代码是没有问题的，而且你上班是为了解决问题，而不是重新发明轮子。 大多数情况下，复制代码的优势非常明显，小心对待的话问题也不大。至少那些从靠谱的来源获得的代码已经被大致“检查“过了。 问题的复杂之处在于，这些共享代码是否存在一些未发现的错误，代码的用途或底层数据是否存在一些特别的假设。也许你的代码混入了空指针，而原始代码从未检查过。如果你能解决这些问题，那么就可以理解为你的老板得到了两位程序员共同努力的成果。这就是某种形式的结对编程，而且用不着什么高大上的办公桌。 不良的编程习惯TOP2：非函数式代码 在过去十年间，函数范式愈加流行。喜欢用嵌套函数调用来构建程序的人们引用了很多研究成果。这些研究表明，与旧式的变量和循环相比，函数式编程代码更安全，错误更少，而且可以随程序员的喜好任意组合在一起。粉丝们十分追捧函数式编程，还会在代码审查和拉取请求中诋毁非函数式方法。关于这种方法的优势，他们的观点其实并没有错。 但有时你需要的仅仅是一卷胶带而已。精心设计并细心计划的代码需要花费很多时间，不仅需要花费时间想象，还需要构建和之后导航的时间。这些都增加了复杂性，并且会花费很多的时间与精力。开发漂亮的函数式代码需要提前做计划，还要确保所有数据都通过正确的途径传递。有时找出并更改变量会简单得多，可能再加个注释说明一下就够了。就算要在注释中为之后的程序员致以冗长而难懂的歉意，也比重新设计整个系统，把它扳回正轨上要省事得多。 不良的编程习惯第 3 位：非标准间距 软件中的大多数空格都不会影响程序的性能。除少数使用间距指示代码块的语言（如 Python）外，大多数空格对程序行为的影响为零。尽管如此，仍然有一些得了强迫症的程序员会数空格，并坚持认为它们很重要。曾有这样一位程序员以最严肃的口吻告诉我的老板，说我正在写“非标准代码”，还说他一眼就看出来了。我的错咯？因为我没在等号的两侧放置空格，违反了 ESLint space-infix-ops 规则[1]。 有时候你只要操心那些更深层的内容就行了，谁管什么空格的位置。也许你担心数据库过载，也许你担心空指针可能会让你的代码崩溃。一套代码中，几乎所有的部分都比空格更重要，就算那些喜欢走形式的标准委员会写出来一大堆规则来限制这些空格或制表符的位置，那又如何呢。 令人欣喜的是，网上可以找到一些很好用的工具来自动重新格式化你的代码，让你的代码遵守所有精心定义的 linting 规则。人类不应该在这种事情上浪费时间和脑细胞。如果这些规则这么重要，我们就应该用工具来解决这些问题。 不良的编程习惯第 4 位：使用 goto 禁止使用 goto 的规则可以追溯到许多结构化编程工具还没有出现的时代。如果程序员想创建一个循环或跳转到另一个例程，则需要键入 goto，后跟一个行号。多年之后，编译器团队开始允许程序员使用字符串标签来代替行号。这在当时被认为是一项热门的新特性。 有的人把这样做法的结果称为“意大利面条式代码”。因为以后没人能读懂你的代码，没人搞得清楚执行路径。成为一团混乱的线程，缠结在一起。Edsger Dijkstra 写过一篇题为“我们认为 goto 声明是有害的”的一篇文章[2]，号召大家拒绝使用这个命令。 但是绝对分支并不是问题所在，问题在于它产生的那堆纠缠的结果。一般来说，精心设计的 break 或 return 能提供有关该位置的代码执行情况的非常清晰的陈述。有时，将 goto 添加到一个 case 语句中所生成的东西与联 if-then-else 块的相比，结构更正确的列表理解起来更容易。 也有反例。苹果 SSL 堆栈中的“goto fail”安全漏洞[3]就是一个很好的例子。但是，如果我们谨慎地避免 case 语句和循环中出现的一些问题，我们就可以插入很好用的绝对跳转，使代码读者更容易理解正在发生的事情。有时我们可以放一个 break 或 return，不仅更简洁，而且大家读起来更愉快，除了那些讨厌 goto 的人们。 不良的编程习惯第 5 位：不声明类型 热爱类型化语言的人们有他们的理由。当我们为每个变量的数据类型添加清晰的声明时，我们会编写更好，错误更少的代码。花点时间来阐明类型，就可以帮助编译器在代码开始运行之前标记出愚蠢的错误。这可能会很痛苦，但也会有回报。这是一种编程的笨办法，就是为了避免错误。 时代变了。许多较新的编译器已经足够聪明了，它们可以在查看代码时推断出类型。它们可以在代码中前后移动，最后确认变量应该是 string 或 int，抑或是其他类型。而且，如果推断出来的这些类型没法对齐，则编译器会给出错误标志。它们不需要我们再类型化变量了。 换句话说，我们可以省略一些最简单的声明，然后就能轻松节省一些时间了。代码变得更简洁，代码读者也往往能猜出 for 循环中名为 i 的变量是一个整数。 不良的编程习惯第 6 位：溜溜球代码 程序员喜欢将其称为“yo-yo 代码”。首先，这些值将存储为字符串，然后将它们解析为整数，接下来将它们转换回字符串。这种方法效率极低。你几乎能感受到一大堆额外负载让 CPU 不堪重负的样子。能快速编写代码的聪明程序员会调整自己的代码架构，以最大程度地减少转换。因为他们安排好了计划，他们的代码也能跑得更快。 但不管你信不信，有时溜溜球代码也是有意义的。有的时候，你需要用一个可以在自己的黑匣子里搞定一大堆智能操作的库。有的老板花了很多钱，请好多天才做出来这么一个库。如果这个库需要字符串形式的数据，那么你就得给它字符串，就算你最近刚把数据转换为整数也得再转回去。 当然，你可以重写所有代码以最大程度地减少转换，但这会花费一些时间。有时，代码多运行一分钟、一小时、一天甚至一周也是可以接受的，因为重写代码会花费更多时间。有时候，增加技术债务要比重新建立一笔技术债的成本更低些。 有时这种库里面不是专有代码，而是你很久以前编写的代码。有时，转换一次数据要比重写该库中的所有内容更省事。这种时候你就可以编写悠悠球代码了，不要怕，我们都遇到过这种事情。 不良的编程习惯第7位：编写自己的数据结构 有一条标准规则是，程序员在大二学完数据结构课程后，再也不要编写用于存储数据的代码了。已经有人编写过了我们所需要的所有数据结构，并且他们的代码经过了多年的测试和重新测试。这些结构与语言打包在一起，还可能是免费的。你自己写的代码只会是一堆错误。 但有的时候数据结构库的速度有点缓慢。有时候我们被迫使用的标准结构并不适合我们自己的代码。有时，库会要求我们在使用它的结构之前重新配置数据。有时，这些库带有笨重的保护，还有一些诸如线程锁定之类的特性，而我们的代码并不需要它们。 发生这种情况时就该编写我们自己的数据结构了。有时我们自己的结构会快很多，还可能让我们的代码更整洁，因为我们不需要一大堆额外的代码来重新精确地格式化数据。 不良的编程习惯第 8 位：老式循环 很久以前，创建 C 语言的某人想将所有抽象可能性封装在一个简单的构造中。这个构造开始时要做一些事情，每次循环都要做一些事情，所有事情都完成时还有一些方法来提示我们。当时，这似乎是一种拥有无限可能性的完美语法。 此一时彼一时，如今一些现代评论者只看到了其中的麻烦，发生的事情太多了，所有这些可能性既可能向善也可能作恶。这种构造让阅读和理解代码变得非常困难。他们喜欢更加函数式的的范式，其中没有循环，只有应用到列表的函数，还有映射到某些数据的计算模板。 有时无循环方法更简洁，尤其是当我们只有一个简单的函数和一个数组的时候。但还有些时候，老式的循环要简单得多，因为它可以做更多事情。例如，当你找到第一个匹配项后就立刻停止搜索，这样的代码就简单得多。 此外，要对数据执行多项操作时，映射函数会要求更严格的编码。假设你要对每个数字取绝对值，然后取平方根，最快的方案是先映射第一个函数，然后映射第二个函数，将数据循环两次。 不良的编程习惯第 9 位：在中间打破循环 从有一天开始，一个规则制定小组宣布每个循环都应该有一个“不变项”，就是一个在整个循环中都为真的逻辑语句。当不变量不再为真时，循环就结束了。这是处理复杂循环的好方法，但会带来一些令人抓狂的约束，例如禁止我们在循环中间使用 return 或 break。这条规则是禁止 goto 语句规则的子集。 这个理论很不错，但它通常会导致代码变得更复杂。考虑以下这种简单的情况，其中会扫描一个数组，找出通过测试的一个条目： while (i<a.length){ ... if (test(a[i]) then return a[i]; ... } 喜欢循环不变项的人们宁愿我们添加另一个布尔变量，将其称为 notFound，然后这样用它： while ((notFound) && (i<a.length){ ... if (test(a[i])) then notFound=false; ... } 如果这个布尔名称取得很合适，那就会是一段自我注释得很好的代码。它可以让大家理解起来更容易。但这也增加了复杂性。这还意味着要分配另一个局部变量并阻塞一个寄存器，编译器可能没那么聪明，没法修复这个错误。 有时使用 goto 或 jump 会更简洁。 不良的编程习惯第10位：重载运算符和函数 一些有趣的语言会让你绕一些大弯子，比如说重新定义看起来应该是常量的元素值。拿 Python 来说，至少在 2.7 版及更低版本中，它允许你键入 TRUE=FALSE。这不会引发某种逻辑崩溃，也不会导致宇宙的终结；它只是交换了 TRUE 和 FALSE 的含义。你还可以使用 C 预处理器和其他一些语言来玩这种危险的游戏。还有一些语言允许你重新定义加号之类的运算符。 有时候，在一大段代码中重新定义一个或一些所谓常量，结果效率会更高。有时，老板会希望代码执行完全不同的操作。当然，你可以检查代码，逐一更改对应的部分，也可以干脆重新定义现实来节省时间。别人会觉得你是天才。用不着重写庞大的库，只需翻转一下即可。 这里也许应该划一条底线。无论这种做法多有意思，看起来多聪明，你都不应该在家里做实验。这太危险了——我是认真的。

Go 的优势在于能够将简单的和经过验证的想法结合起来，同时避免了其他语言中出现的许多问题。本文概述了 Go 背后的一些设计原则和工程智慧，作者认为，Go 语言具备的所有这些优点，将共同推动其成为接替 Java 并主导下一代大型软件开发平台的最有力的编程语言候选。很多优秀的编程语言只是在个别领域比较强大，如果将所有因素都纳入考虑，没有其他语言能够像 Go 语言一样“全面开花”，在大型软件工程方面，尤为如此。 基于现实经验 Go 是由经验丰富的软件行业老手一手创建的，长期以来，他们对现有语言的各种缺点有过切身体会的痛苦经历。几十年前，Rob Pike 和 Ken Thompson 在 Unix、C 和 Unicode 的发明中起到了重要作用。Robert Griensemer 在为 JavaScript 和 Java 开发 V8 和 HotSpot 虚拟机之后，在编译器和垃圾收集方面拥有数十年的经验。有太多次，他们不得不等待 Google 规模的 C++/Java 代码库进行编译。于是，他们开始着手创建新的编程语言，将他们半个世纪以来的编写代码所学到的一切经验包含进去。 专注于大型工程 小型工程项目几乎可以用任何编程语言来成功构建。当成千上万的开发人员在数十年的持续时间压力下，在包含数千万行代码的大型代码库上进行协作时，就会发生真正令人痛苦的问题。这样会导致一些问题，如下： 较长的编译时间导致中断开发。代码库由几个人 / 团队 / 部门 / 公司所拥有，混合了不同的编程风格。公司雇佣了数千名工程师、架构师、测试人员、运营专家、审计员、实习生等，他们需要了解代码库，但也具备广泛的编码经验。依赖于许多外部库或运行时，其中一些不再以原始形式存在。在代码库的生命周期中，每行代码平均被重写 10 次，被弄得千疮百痍，而且还会发生技术偏差。文档不完整。 Go 注重减轻这些大型工程的难题，有时会以使小型工程变得更麻烦为代价，例如，代码中到处都需要几行额外的代码行。 注重可维护性 Go 强调尽可能多地将工作转给自动化的代码维护工具中。Go 工具链提供了最常用的功能，如格式化代码和导入、查找符号的定义和用法、简单的重构以及代码异味的识别。由于标准化的代码格式和单一的惯用方式，机器生成的代码更改看起来非常接近 Go 中人为生成的更改并使用类似的模式，从而允许人机之间更加无缝地协作。 保持简单明了 初级程序员为简单的问题创建简单的解决方案。高级程序员为复杂的问题创建复杂的解决方案。伟大的程序员找到复杂问题的简单解决方案。 ——Charles Connell 让很多人惊讶的一点是，Go 居然不包含他们喜欢的其他语言的概念。Go 确实是一种非常小巧而简单的语言，只包含正交和经过验证的概念的最小选择。这鼓励开发人员用最少的认知开销来编写尽可能简单的代码，以便许多其他人可以理解并使用它。 使事情清晰明了 良好的代码总是显而易见的，避免了那些小聪明、难以理解的语言特性、诡异的控制流和兜圈子。 许多语言都致力提高编写代码的效率。然而，在其生命周期中，人们阅读代码的时间却远远超过最初编写代码所需的时间（100 倍）。例如，审查、理解、调试、更改、重构或重用代码。在查看代码时，往往只能看到并理解其中的一小部分，通常不会有完整的代码库概述。为了解释这一点，Go 将所有内容都明确出来。 错误处理就是一个例子。让异常在各个点中断代码并在调用链上冒泡会更容易。Go 需要手动处理和返回每个错误。这使得它可以准确地显示代码可以被中断的位置以及如何处理或包装错误。总的来说，这使得错误处理编写起来更加繁琐，但是也更容易理解。 简单易学 Go 是如此的小巧而简单，以至于人们可以在短短几天内就能研究通整个语言及其基本概念。根据我们的经验，培训用不了一个星期（相比于掌握其他语言需要几个月），初学者就能够理解 Go 专家编写的代码，并为之做出贡献。为了方便吸引更多的用户，Go 网站提供了所有必要的教程和深入研究的文章。这些教程在浏览器中运行，允许人们在将 Go 安装到本地计算机上之前就能够学习和使用 Go。 解决之道 Go 强调的是团队之间的合作，而不是个人的自我表达。 在 Go（和 Python）中，所有的语言特性都是相互正交和互补的，通常有一种方法可以做一些事情。如果你想让 10 个 Python 或 Go 程序员来解决同一个问题，你将会得到 10 个相对类似的解决方案。不同的程序员在彼此的代码库中感觉更自在。在查看其他人的代码时，国骂会更少，而且人们的工作可以更好地融合在一起，从而形成了一致的整体，人人都为之感到自豪，并乐于工作。这还避免了大型工程的问题，如： 开发人员认为良好的工作代码很“混乱”，并要求在开始工作之前进行重写，因为他们的思维方式与原作者不同。 不同的团队成员使用不同的语言子集来编写相同代码库的部分内容。  简单、内置的并发性 Go 专为现代多核硬件设计。 目前使用的大多数编程语言（Java、JavaScript、Python、Ruby、C、C++）都是 20 世纪 80 年代到 21 世纪初设计的，当时大多数 CPU 只有一个计算内核。这就是为什么它们本质上是单线程的，并将并行化视为边缘情况的马后炮。通过现成和同步点之类的附加组件来实现，而这些附加组件既麻烦又难以正确使用。第三方库虽然提供了更简单的并发形式，如 Actor 模型，但是总有多个可用选项，结果导致了语言生态系统的碎片化。今天的硬件拥有越来越多的计算内核，软件必须并行化才能高效运行。Go 是在多核处理器时代编写的，并且在语言中内置了简单、高级的 CSP 风格并发性。 面向计算的语言原语 就深层而言，计算机系统接收数据，对其进行处理（通常要经过几个步骤），然后输出结果数据。例如，Web 服务器从客户端接收 HTTP 请求，并将其转换为一系列数据库或后端调用。一旦这些调用返回，它就将接收到的数据转换成 HTML 或 JSON 并将其输出给调用者。Go 的内置语言原语直接支持这种范例： 结构表示数据 读和写代表流式 IO 函数过程数据 goroutines 提供（几乎无限的）并发性 在并行处理步骤之间传输管道数据 因为所有的计算原语都是由语言以直接形式提供的，因此 Go 源代码更直接地表达了服务器执行的操作。 OO — 好的部分 更改基类中的某些内容的副作用 面向对象非常有用。过去几十年来，面向对象的使用富有成效，并让我们了解了它的哪些部分比其他部分能够更好地扩展。Go 在面向对象方面采用了一种全新的方法，并记住了这些知识。它保留了好的部分，如封装、消息传递等。Go 还避免了继承，因为它现在被认为是有害的，并为组合提供了一流的支持。 现代标准库 目前使用的许多编程语言（Java、JavaScript、Python、Ruby）都是在互联网成为当今无处不在的计算平台之前设计的。因此，这些语言的标准库只提供了相对通用的网络支持，而这些网络并没有针对现代互联网进行优化。Go 是十年前创建的，当时互联网已全面发展。Go 的标准库允许在没有第三方库的情况下创建更复杂的网络服务。这就避免了第三方库的常见问题： 碎片化：总是有多个选项实现相同的功能。 膨胀：库常常实现的不仅仅是它们的用途。 依赖地狱：库通常依赖于特定版本的其他库。 未知质量：第三方代码的质量和安全性可能存在问题。 未知支持：第三方库的开发可能随时停止支持。 意外更改：第三方库通常不像标准库那样严格地进行版本控制。 关于这方面更多的信息请参考 Russ Cox 提供的资料 标准化格式 Gofmt 的风格没有人会去喜欢，但人人都会喜欢 gofmt。 ——Rob Pike Gofmt 是一种以标准化方式来格式化 Go 代码的程序。它不是最漂亮的格式化方式，但却是最简单、最不令人生厌的格式化方式。标准化的源代码格式具有惊人的积极影响： 集中讨论重要主题： 它消除了围绕制表符和空格、缩进深度、行长、空行、花括号的位置等一系列争论。 开发人员在彼此的代码库中感觉很自在， 因为其他代码看起来很像他们编写的代码。每个人都喜欢自由地按照自己喜欢的方式进行格式化代码，但如果其他人按照自己喜欢的方式格式化了代码，这么做很招人烦。 自动代码更改并不会打乱手写代码的格式，例如引入了意外的空白更改。 许多其他语言社区现在正在开发类似 gofmt 的东西。当作为第三方解决方案构建时，通常会有几个相互竞争的格式标准。例如，JavaScript 提供了 Prettier 和 StandardJS。这两者都可以用，也可以只使用其中的一个。但许多 JS 项目并没有采用它们，因为这是一个额外的决策。Go 的格式化程序内置于该语言的标准工具链中，因此只有一个标准，每个人都在使用它。 快速编译  对于大型代码库来说，它们长时间的编译是促使 Go 诞生的原因。Google 主要使用的是 C++ 和 Java，与 Haskell、Scala 或 Rust 等更复杂的语言相比，它们的编译速度相对较快。尽管如此，当编译大型代码库时，即使是少量的缓慢也会加剧编译的延迟，从而激怒开发人员，并干扰流程。Go 的设计初衷是为了提高编译效率，因此它的编译器速度非常快，几乎没有编译延迟的现象。这给 Go 开发人员提供了与脚本类语言类似的即时反馈，还有静态类型检查的额外好处。 交叉编译 由于语言运行时非常简单，因此它被移植到许多平台，如 macOS、Linux、Windows、BSD、ARM 等。Go 可以开箱即用地为所有这些平台编译二进制文件。这使得从一台机器进行部署变得很容易。 快速执行 Go 的运行速度接近于 C。与 JITed 语言（Java、JavaScript、Python 等）不同，Go 二进制文件不需要启动或预热的时间，因为它们是作为编译和完全优化的本地代码的形式发布的。Go 的垃圾收集器仅引入微秒量级的可忽略的停顿。除了快速的单核性能外，Go 还可以轻松利用所有的 CPU 内核。 内存占用小 像 JVM、Python 或 Node 这样的运行时不仅仅在运行时加载程序代码，每次运行程序时，它们还会加载大型且高度复杂的基础架构，以进行编译和优化程序。如此一来，它们的启动时间就变慢了，并且还占用了大量内存（数百兆字节）。而 Go 进程的开销更小，因为它们已经完全编译和优化，只需运行即可。Go 还以非常节省内存的方式来存储数据。在内存有限且昂贵的云环境中，以及在开发过程中，这一点非常重要。我们希望在一台机器上能够快速启动整个堆栈，同时将内存留给其他软件。 部署规模小 Go 的二进制文件大小非常简洁。Go 应用程序的 Docker 镜像通常比用 Java 或 Node 编写的等效镜像要小 10 倍，这是因为它无需包含编译器、JIT，以及更少的运行时基础架构的原因。这些特点，在部署大型应用程序时很重要。想象一下，如果要将一个简单的应用程序部署到 100 个生产服务器上会怎么样？如果使用 Node/JVM 时，我们的 Docker 注册表就必须提供 100 个 docker 镜像，每个镜像 200MB，那么一共就需要 20GB。要完成这些部署就需要一些时间。想象一下，如果我们想每天部署 100 次的话，如果使用 Go 服务，那么 Docker 注册表只需提供 10 个 docker 镜像，每个镜像只有 20MB，共只需 2GB 即可。大型 Go 应用程序可以更快、更频繁地部署，从而使得重要更新能够更快地部署到生产环境中。 独立部署 Go 应用程序部署为一个包含所有依赖项的单个可执行文件，并无需安装特定版本的 JVM、Node 或 Python 运行时；也不必将库下载到生产服务器上，更无须对运行 Go 二进制文件的机器进行任何更改。甚至也不需要讲 Go 二进制文件包装到 Docker 来共享他们。你需要做的是，只是将 Go 二进制文件放到服务器上，它就会在那里运行，而不用关心服务器运行的是什么。前面所提到的那些，唯一的例外是使用net和os/user包时针对对glibc的动态链接。 供应依赖关系 Go 有意识避免使用第三方库的中央存储库。Go 应用程序直接链接到相应的 Git 存储库，并将所有相关代码下载（供应）到自己的代码库中。这样做有很多好处： 在使用第三方代码之前，我们可以对其进行审查、分析和测试。该代码就和我们自己的代码一样，是我们应用程序的一部分，应该遵循相同的质量、安全性和可靠性标准。 无需永久访问存储依赖项的各个位置。从任何地方（包括私有 Git repos）获取第三方库，你就能永久拥有它们。 经过验收后，编译代码库无需进一步下载依赖项。 若互联网某处的代码存储库突然提供不同的代码，这也并不足为奇。 即使软件包存储库速度变慢，或托管包不复存在，部署也不会因此中断。 兼容性保证 Go 团队承诺现有的程序将会继续适用于新一代语言。这使得将大型项目升级到最新版本的编译器会非常容易，并且可从它们带来的许多性能和安全性改进中获益。同时，由于 Go 二进制文件包含了它们需要的所有依赖项，因此可以在同一服务器上并行运行使用不同版本的 Go 编译器编译的二进制文件，而无需进行复杂的多个版本的运行时设置或虚拟化。 文档 在大型工程中，文档对于使软件可访问性和可维护性非常重要。与其他特性类似，Go 中的文档简单实用： 由于它是嵌入到源代码中的，因此两者可以同时维护。 它不需要特殊的语法，文档只是普通的源代码注释。 可运行单元测试通常是最好的文档形式。因此 Go 要求将它们嵌入到文档中。 所有的文档实用程序都内置在工具链中，因此每个人都使用它们。 Go linter 需要导出元素的文档，以防止“文档债务”的积累。 商业支持的开源 当商业实体在开放式环境下开发时，那么一些最流行的、经过彻底设计的软件就会出现。这种设置结合了商业软件开发的优势——一致性和精细化，使系统更为健壮、可靠、高效，并具有开放式开发的优势，如来自许多行业的广泛支持，多个大型实体和许多用户的支持，以及即使商业支持停止的长期支持。Go 就是这样发展起来的。 缺点 当然，Go 也并非完美无缺，每种技术选择都是有利有弊。在决定选择 Go 之前，有几个方面需要进行考虑考虑。 未成熟 虽然 Go 的标准库在支持许多新概念（如 HTTP 2 Server push 等）方面处于行业领先地位，但与 JVM 生态系统中的第三方库相比，用于外部 API 的第三方 Go 库可能不那么成熟。 即将到来的改进 由于清楚几乎不可能改变现有的语言元素，Go 团队非常谨慎，只在新特性完全开发出来后才添加新特性。在经历了 10 年的有意稳定阶段之后，Go 团队正在谋划对语言进行一系列更大的改进，作为 Go 2.0 之旅的一部分。 无硬实时 虽然 Go 的垃圾收集器只引入了非常短暂的停顿，但支持硬实时需要没有垃圾收集的技术，例如 Rust。 结语 本文详细介绍了 Go 语言的一些优秀的设计准则，虽然有的准则的好处平常看起来没有那么明显。但当代码库和团队规模增长几个数量级时，这些准则可能会使大型工程项目免于许多痛苦。总的来说，正是这些设计准则让 Go 语言成为了除 Java 之外的编程语言里，用于大型软件开发项目的绝佳选择。