『每周译Go』写了 50 万行 Go 代码后，我明白这些道理

早在 2019 年 12 月，我第一次写一个关于 Goliath 的可汗学院的项目，该项目的目的是将我们的后端从 python2 整体迁移到 Go 编写的服务上，以及在该过程中的一些其他必要的改变。另外，我也写了一篇关于我们是如何逐步实现这种改变的博客。

当我们开始 Goliath 的时候，我们团队没有一个人知道 Go，直到我们进行实验才发现相比于其他语言，Go 对我们来说是最好的选择。今天，我们所有的后端和全栈工程师都在写 Go ，Goliath 的增量交付让我们跨越了一个重大的里程碑：目前，超过 50 万行 Go 代码运行在我们的生产环境中。这似乎是一个对 Go 本身进行反思的好时机。

我们的工程师喜爱 Go 语言

我向 Go 工程师询问了一些关于 Go 的开放式问题，我听到的反馈是 “读起来和写起来都很容易” 和 “我越用越喜欢!”。

一位工程师在 .NET 领域工作多年，推崇 exception 风格的错误处理，这与 Go 的错误处理非常不同。如果你对这方面不熟悉，你可以理解为 Go 的错误都是存在错误条件的函数的返回值。我们的前.NET 工程师现在说，“能够调用一个没有返回错误的函数，并且确信它一定会成功，这真的很棒。

另外一个工程师引用了 Go 的标准库文档。他喜欢 可以通过 go doc io.Writer等方式获得离线浏览文档体验。100% 最好的文档，可以反复阅读。

Renee French 的吉祥物地鼠也因给这门语言带来了乐趣和可爱而备受赞誉。

总的来说，Go 工具很棒。编译速度很快，并且将格式化作为标准工具链的一部分，这有助于消除大多数关于格式化的争议。尽管我仍在互联网上看到关于 Go module 的抱怨，但是它比以前的 Go 包管理工具要好很多，关于这包管理一块，从我们的经验来看整体上还算不错。我们还可以毫不费力找到所需的工具和库，比如 gqlgen。

我们想要泛型，不然的话 Go 有点冗长

大多数时候，没有泛型写 Go 代码是可以的。但也有很多时候，当我们在写内部库代码或者当我们在使用 slices 的时候，我们会感受到泛型的缺失。

缺少泛型是人们对 Go 的最大抱怨。我调查过的工程师，他们对于 Go 团队花时间来开发适合 Go 的泛型这一事实，非常欣赏。我们对这项工作的进展也感到兴奋。等到 Go 泛型正式发布的时候，我们至少还得花几年功夫去使用。

在移植 python 代码时，一位工程师指出，对于特定的语言结构使用 Go 语言花费更多的努力，但是 Go 相对较少的语言特性使得代码更加一致，阅读速度更快。对于我们系统的某一部分，和 python 代码相比，我们需要 2.7 倍的 Go 代码来处理同样的特性。虽然这部分是由于用跨服务查询替换了一些函数调用。

另外一个工程师希望能够更好地利用高阶函数，这个 slices 包的提议是对这方面很好的补充。最终，我们希望能少写一点代码，而选择泛型将对此有所帮助。

性能和并发

从 python（不少是 python2）转过来，我们发现 Go 的性能表现非常出色。我们尽可能按照 1:1 的方式将 python 移植到 Go，直到最后会得到类似 Go 的东西，而不是像 Python-in-Go 那样的代码。在这个过程中，我们没有明确地以性能优先，除非有真正性能瓶颈。

一位工程师指出，某些批量数据更改在 python 版本中每小时会产生大约 100 多个谷歌云数据存储（Google Cloud Datastore）争用告警，而在 Go 版本中几乎没有，因为 Go 的处理数据速度非常快。我们有一个异常的例子，一个包含 1000 个学生的类，在 python 中加载需要 28 秒，而在 Go 中只需要 4 秒。

虽然我们是从主要为单线程的 python 直接移植过来，但是我们已经使用了一些 Go 的并发特性。一位工程师指出，虽然通道是 Go 中的一个非常突出的特性，但是我们使用 sync 包的功能远远多于通道。看看我们这个偏好是不是随着时间推移而改变，这会非常有意思。

写完 50 万行 Go 代码后

总结：

• 是的，Go 通常比 python 更冗长 ...

• 但是我们喜欢它，它速度快，工具稳定，而且在生产中运行良好

我们的工程师来自不同的编程背景，所以我们对于 Go 和其他语言有着不同的看法。也就是说，当我们启动一个项目时，Go 能够胜任我们赋予它的工作。我们很感谢 Go 团队能够推动它的持续发展，并且围绕着它构建社区。