我不喜欢Go语言的十个理由

以小写字母开头的标识符在包内可见，以大写字母开头的标识符是公开的。这样做可能是为了省掉 public 和 private 关键字，但是，首字母大写已经被用来表示其他意思——比如类名的首字母是大写的，常量完全是大写的。对于我来说，使用完全小写的字母来定义全局常量实在是有点不适应。

如果你要定义私有结构体，情况会变得更加糟糕，因为你必须使用小写字母。例如，你可能有一个结构体叫作 user，那么你会怎么定义这个结构体的变量呢？你可能会把它叫作 user，这样看起来是不是有点奇怪？因为变量的名字跟结构体的名字是一样的，而且如果编译器也搞不清楚哪个是哪个，就会抛出编译错误。

type user struct {
   name string
}

func main() {
   var user *user
   user = &user{} // Compile error
}

Go 语言通常会使用比较短的命名方式，比如 u。但是，35 年前，当我还在使用古董机 TRS-80 Basic 的时候就已经不再使用这种单字母的命名方式了。

当然，也有一些与实际开发相关的考虑。比如经常会出现这样的情况：刚开始定义了一个私有字段或结构体，后来需要把它们变成公开的，这样就不得不把所有使用这些标识符的地方都修改一遍。即使你不需要把它们变成公开的，但如果要使用 json 包来序列化它们，也不得不这么做。我就曾经定义过一个包含 74 个私有字段的结构体，因为要使用 json 序列化，不得不把所有字段都变成公开的，并且修改了所有使用这些字段的地方。

通过首字母大写的方式来决定可见性有一定的局限性（要么包内可见，要么公开）。例如，我经常需要使用文件内部可见的私有标识符，但目前 Go 语言不太可能引入这样的东西。

这种设计犯了一个根本性的错误：它假设两个方法如果有相同的签名就表示有相同的契约。在 Java 中，如果一个类实现了一个接口，它会告诉编译器它实现了接口的所有方法。如果一个方法返回布尔类型，接口的注释会写清楚它的值代表什么意思（比如，true 表示成功，false 表示失败）。

但是，Go 语言的结构体可能一方面实现了同样的接口，但返回值的意思却是相反的。具体怎么实现可以自由发挥，因为并没有接口声明约束。当然，在 Java 里也可以这么做，但这很显然就是一个 bug。而在 Go 语言中，一个程序员可能在没有验证方法兼容性的情况下将一个对象转成某个接口，这样很容易引入潜在的 bug。验证兼容性的负担不应该强加给 API 使用者，应该由结构体的实现者承担，并在代码中声明清楚。

开发者会容易忘了检查返回值里是不是包含了错误。
 

db.Exec("DELTE FROM item WHERE id = 2")

在这个语句里，DELETE 拼写错误，但没有任何消息告诉你出了什么问题。如果这个语句是一个大型事务的一部分，那么整个事务就什么事都不会做。通过返回值表示错误不是个问题，但程序员必须去检查返回值，或者把它赋值给 _。

另外，看一下这个语句：
 

user, err := getUserById(userId)

它并不保证 user 或 err 会包含正确的值。user 有可能没有被赋值（于是读取这个变量就会出现警告），而如果使用了联合类型，编译器只保证正确的那个可以被访问。

例如，如果我把源码文件命名为 i_love_linux.go，在 Mac 上就编译不过去。而如果我凑巧把一个函数名定义成 init()，在运行时它会自动被调用。这些都是“约定俗成而非配置（convention over configuration）”的表现。对于小型项目来说，这些都无关键要，但在大型项目中，它们会给你带来大麻烦。

比如，一些包名、结构体名和变量名都叫作 item。在 Java 中，包名使用了全限定名，类名首字母是大写的。有时候，我觉得 Go 代码不好阅读，因为可能无法一下子看出一个标识符的作用域是怎样的。

编译器太过敏感，一些未被使用的导入和变量也会导致构建失败。在生成大型文件时，它在一开始可能并不知道需要导入那些包，而且可能会出现包名冲突，这种冲突也不好处理，因为即使你知道包名，却不知道导入的符号来自哪里。即使你知道，生成的代码为了避免冲突也会强制使用别名。在 Java 中，这些问题可以通过使用全限定类名来解决，而在 Go 语言中是不能这样做的。

C 语言风格的编程语言都提供了这个运算符。在使用 Go 语言时，我无时不刻都在想念着这个运算符。当每个人都觉得这个运算符很有用的时候，Go 语言却把它移除掉了。原来很优雅的语句，比如：
 

var serializeType = showArchived ? model.SerializeAll : model.SerializeNonArchivedOnly

不得不写成这样：
 

var serializeType model.SerializeType
if showArchived {
  serializeType = model.SerializeAll
} else {
  serializeType = model.SerializeNonArchivedOnly
}

如果你有 10 个不同的结构体需要排序，必须写 30 个函数，其中有 20 个是几乎一样的。而且代码写起来很麻烦，你或许可以把它们委托给另一个 Less()，但你必须保证 Len() 和 Swap() 是兼容的。而且这样的代码看起来很奇怪，转型看起来像是在调用函数：
 

sort.Sort(sort.Reverse(UsersByLastSignedInAt(users)))

我真的不想使用一门无法实现 Stack 泛型类的语言。临时的解决方案是使用 append() 函数替代，但现在都什么年代了，我可不想写像下面这样的代码：
 

stack = append(stack, object)

object = stack[len(stack) - 1]
stack = stack[:len(stack) - 1]

我很好奇究竟有多少第三方库使用了 interface{}。可见 Go 语言的类型系统设计得非常糟糕。

append() 函数用于扩展一个数组，然后返回新数组：
 

users = append(users, newUser)

但下面这行代码总是能够调用成功：
 

append(users, newUser)

append() 函数在可能的情况下进行原地数组修改，如果没有足够的空间就返回一个新的数组。这样的 API 设计真是再糟糕不过了。有多少 bug 是因为忘记把结果赋值给变量引起的？有很多。因为即使是在测试时也不一定会触发数组调整大小（这里需要说明一下，后来他们修改了编译器，如果 append() 函数没有被赋值给变量，就抛出错误）。

这是我个人对使用 Go 语言的一些建议：如果你的程序很小，基本上可以说清楚要实现什么功能，并且不会与太多外部数据（数据库、Web 等）打交道，那么使用 Go 语言是没有问题的。如果程序很大，有很复杂的数据结构，或者需要处理大量的外部数据，那么 Go 语言的类型系统会让你抓狂，你最好选择其他静态类型的语言（类型系统比较完善）或者动态语言（不会碍手碍脚）。

虽然这篇文章并非最近刚刚发布，但它这一次登上 HackerNews 后依然引发了网友的热烈讨论，收获了数百个讨论并在很短的时间里再次登上 HackerNews 热度榜。有的网友对作者的观点表示认同，并表示虽然会将 Go 语言作为一种备用的编程语言，但如无必要不会再去用它。有的网友则觉得作者提出的大部分缺点都不是问题，并希望 Go 语言保持初心，不要随意修改。以下是我们整理的网友精彩评论。

网友lostingthefight：

我从 2015 年开始就在生产环境中使用 Go 语言。说实话，除了三元运算符，其他的对我来说都不是问题。我主要从事 REST API 方面的开发，所以面对的场景可能不太一样。首字母大写和接口实现问题对我来说也不是个事。Go 语言提供的一些特性在我所使用过的语言中是最好的。再配合一个好的编辑器，就不会错过任何异常。

不过不管怎样，Go 语言并不完美。有时候 Go 例程很难追踪，而且对于大型项目来说，模块过度是个麻烦事。不过，如果有得选择，我还是不会回到 Java、C#、PHP 或者 NodeJS。

网友kstenerud：

即使是在中型项目中，我也受到了这些问题的困扰。未使用的导入和变量会导致编译错误，这点实在很令人厌烦，所以不得不给编译器打个补丁（https://github.com/kstenerud/go），把它们变成警告，而不是错误。

网友cr0sh：

离最后一次使用 Go 语言已经很长一段时间了。我还记得当初学习 Go 语言的经历。我和我的同事被安排为我们的雇主（一家云服务提供商）开发一个接口，允许 Rancher（或者 Rancher 的客户端，具体忘了是哪个了）使用我们的后端系统（使用 PHP、Java 和 Bash 开发的）来分配服务器。

Rancher 是使用 Go 语言开发的，但我们都没接触过 Go 语言，我们都是 PHP 开发者，于是我们开始学习 Go 语言。

我们大概花了一个礼拜时间学习 Go 语言，一个月之后，我们就开发出了一个可运行的库，还带有文档和测试代码。但是整个开发过程与文章中所写的差不多（这里略去若干骂人的话）……

我们已经习惯了在 PHP 中放一些临时用的代码，比如为了试验、调试等原因。但是，Go 语言不允许我们这么做。要想编译通过，必须清理掉这些东西，这让我们感到很抓狂，而且日复一日，一周又一周，然后：

我们释然了。我们可以理解为什么 Go 语言的设计者要这样设计，我们甚至希望 PHP 也这么做。我们后来没有再随意乱放临时代码，因为这些代码在后面有可能会给我们带来麻烦。Go 语言的这种设计确实给开发添加了难度，但另一方面却可以帮我们避免出现更多的错误，或者在未来出现更多的 bug，并让代码变得更容易维护。

但不管怎样，我不用 Go 语言已经有好几年时间了，我不再需要它了。但如果有必要，我还是会用它。或许，这几年 Go 语言发生了很多变化，不过也有可能变化并不大。无论如何，我从那次经历中学到了一个道理：在得到你想要的东西之前，必须经历痛苦和挣扎。我体验了一门非常独特的语言，我也因此变成一个更好的开发者。

网友sdegutis：

客观来说，首字母大写是个问题，特别是在改变了可见性之后需要重构代码。不过，使用一个好的 IDE 可以减轻这方面的工作量。更重要的问题是 Go 语言设计者似乎无法体会惯例的重要性。我过去十年所使用的编程语言都鼓励开发者使用变量、类名和常量惯例。

这让我想起了那些想要让人们使用 CE（公元）和 BCE（公元前）代替 AD（公元另一种说法）和 BC（公元前另一种说法）的人，他们忽略了后者的习惯性和相关性，就好像他们生活在真空中。

我不知道该怎么说，但这是我不喜欢 Go 语言最主要的原因。

有人说 Go 语言是一门借鉴了 C 语言特点的新语言。但我觉得这种说法有点夸张，就好像是说：“现在是 1970 年，C 语言不存在，后面 49 年的事情都还没有发生”。

网友dawkins：

我从 2012 年就开始在生产环境中使用 Go 语言，我觉得它是一门非常棒的语言。除了文中提到的第八点之外，其他对我来说都不是问题。

Go 语言设计者把这门语言设计成这样，我是感到满意的，但让我感到困扰的是最近做出的一些变更：模块和 Go 2 提案。我希望他们能够保持最初的愿景不变。

网友lkramer：

文章提到的问题似乎都很合理，但它们都不足以让我讨厌这门语言。或许首字母大写也是困扰我的一个问题，或许设计者当初可能考虑到可以通过 IDE 来减轻重构工作。但不管怎样，要把一些东西从私有变成非私有要修改很多文件可能不是一个好的设计。

我在错误处理方面也吃过几次苦头。我不太喜欢异常，但这个问题可以通过显式忽略变量来解决。

Go 语言并不完美，但从我的经验来看，没有什么比 Go 语言更适合用来开发微服务了。

网友diamondo25：

文章提到的问题都不算是问题。我希望 Go 语言可以这样一路走下去，不要走回老路或者像 Scala 过去几年所做的那样……

网友gerbilly：

我只想说一句话：是否选择一门语言，不要看它的设计，要看它是否可以解决你的问题。

网友dbt00：

Go 语言确实不完美，但我觉得在解决同样的问题时，它比 Java 或 C++ 更高效。对于文中提到的第二点，我并不喜欢作者举的例子。我觉得不管在任何一门语言中都不应该定义这种容易产生混淆的接口。所以，这一点对我来说也不是问题。

对于第三点，我自己开发了一个小插件，用来检查错误。

如果你要对一个片段进行排序，sort.Slice 比 sort.Interface 更好。

泛型已经被确认是个问题，解决方案正在路上……

你现在正在使用 Go 语言吗？你是否喜欢 Go 语言？你认为作者提出的这 10 个理由是 Go 语言的缺点吗？Go 语言有没有什么问题正在困扰着你？欢迎在评论区留下你的观点和故事。

英文原文：

https://www.teamten.com/lawrence/writings/why-i-dont-like-go.html

HackerNews 网站讨论：

https://news.ycombinator.com/item?id=20166806

选 Go 语言还是 Java？知乎问答服务重构实践

用 Go 语言进行编程的利与弊

Go 会接替 Java，成为下一个企业级编程语言吗？

Go 语言很好很强大，但我有几个问题想吐槽

使用 Python 5 年后，我转向了 Go

再见，Python！你好，Go 语言

舍弃 Python，为何知乎选用 Go 重构推荐系统？

2011 年至今，大数据概念火了八年，势头依然强盛。但即便如此，当抛出“工业大数据”的概念时，为何人们还是唏嘘不止，直道落地艰难？小编说：不基于真实工业场景的数据资源、没有系统的竞赛培训和专业的算法工具，开发者当然只能面对行业难题，望而却步。

光说不练假把式！【第三届工业大数据创新竞赛】报名已经开启：庞大的企业真实数据集，工信部、信通院“大家长”的鼎立支持，华为、天泽智云等大厂的技术支持，还有 200000 元奖金池坐等你来！盛夏烈日炎炎，无心学习工作？满腔才识热血，就想挑战自我！那就赶快扫描下图二维码或点击【阅读原文】，查看大赛详情吧：

你也「在看」吗？?