Go 是最令人讨厌的编程语言。与其他语言相比，它以 20% 的复杂度提供了 80% 的实用性。这种讨厌情绪来自那些希望获得 81% 实用性、85% 或 97% 实用性的人。

正如 Rob Pike 所说，没有人否认 87% 的实用性比 80% 更高。问题在于，额外的 7% 实用性需要多出 36% 的工作量。

以下是一些例子。

有人在 HN 上抱怨 结构体标签 (struct tags)没有注释或宏那么强大。我 解释 这是 80/20 设计。

Go 标准库中的 测试支持 仅有几百行代码，多年来变化不大，却提供了你可能需要的所有基本测试功能。它没有提供你可能想到的所有便利功能。这就是 Java 的 jUnit 库所做的，代价是数万行代码和数年无休止的开发。Go 遵循80/20 的设计原则。

Go 语言中的协程相比 C# 或 Rust 的异步编程，是80/20设计。功能和选项没那么多，但复杂度仅为后者的一小部分（对用户和实现者而言）。

当 Go 语言推出时，并没有用户自定义的泛型，但那些需要泛型的内置类型是泛型的：数组/切片、映射、通道。这种80/20设计为 Go 服务了超过十年。

大多数语言无法抗拒以四百倍的成本追求 100% 设计的诱惑。C#、Swift、Rust 都似乎在不断添加新功能的无尽跑道上。即使是最初只是一个70/15语言的 JavaScript，也被那些把工作重心放在为 JavaScript 添加更多功能的人所掌控。

如果80/20很好，那么70/15不会更好吗？不，不会。Go 证明了你可以有一个流行的编程语言而不使用枚举。我认为你不能没有结构体就有一个流行的编程语言。语言的复杂度低于某个临界值时，它就不再有用。

语言的每一个新特性都需要程序员去学习。这比看起来的要多。如果你将函数作为一等概念，工作不仅仅是学习语法和功能。你还需要学习新的编码模式，比如返回函数的函数。你需要了解柯里化，以及如何将函数作为参数传递。你需要不仅知道如何使用这些强大的功能，还要知道何时使用它们，何时不应使用。

你不能跳过这种复杂性。即使你决定不学习如何使用函数作为一等概念，你的同事可能会这样做，你必须能够理解他的代码。或者一个有用的库使用了它，或者教程中提到了它。

这就是为什么 80%以上的语言需要编码规范。由于没有对任何单个程序员可以使用的功能进行限制，数百名程序员无法有效地共同处理 C++代码库，因此 Google 为 C++制定了编码规范，以将 C++从一种 95%的编程语言降低到 90%。

另一项工作则由语言的实现者完成。Swift 在这方面是一个警示。尽管由非常聪明的开发者花费了几乎无限的预算，耗费了十多年的时间开发，但对于一个 Apple 优先考虑的项目来说，Swift 编译器仍然速度慢、容易崩溃，并且缺乏真正的跨平台性。

他们设计了一种他们无法正确实现的语言。相比之下：Go 是一种简单但功能强大的语言，从 1.0 版本开始就具备快速、跨平台和健壮的特性。

本文为译文，英文原文地址（可能需要使用魔法访问或付费会员才可观看）：
https://blog.kowalczyk.info/article/d-2025-06-26/go-is-8020-language.html