我使用 Golang 两年后的总结:优点和令人讨厌的怪癖

过去两年来,我就职于 Assembled ,一直使用 Go 工作。自公司成立以来,Go 就一直是我们的主要后端语言。在我之前的工作中,我混合着使用 Ruby 和 Scala,所以肯定有过一段适应期。总体而言,我发现 Go 的表现基本上与广告宣传的一样:尽管有些怪异,但它非常适合专业工作。

背景介绍

Assembled 是客户支持团队用来管理人员配备和分析的 Web 应用程序。从架构的角度来看,它是一个标准的 Web 应用程序:React 前端通过内部 HTTP API 访问 Go 后端,后者反过来访问 PostgreSQL 数据库。

也就是说,有几个特定的应用程序,我们也必须对其进行优化:

  • 我们维护一个外部 API
  • 我们从基于 Python 的机器学习服务中生成时间序列预测
  • 我们执行相当繁重的批处理,因为我们通过 SFTP 同步请求中心系统的调度。
  • 我们运行相当复杂的优化算法;我的兄弟 John 在 HN 评论 中对此进行了详细的分享。
  • 我们处理令人痛苦的时区和重复事件相关的逻辑

生产中的 Go

我们构建 Assembled,不使用 Python、Java、Haskell(或……),特意决定使用 Go。决定因素可归结为:静态类型、简单性、标准库和速度。在实践中,我所见过的一切都与 Go 在 文档 中所呈现的方式相吻合:

Go 富有 表现力、简洁、干净且高效 ……Go 可以 快速编译 成机器码,同时还具有垃圾收集的便利性及运行时反射的能力。这是一种 快速的、静态类型的编译 语言,但它感觉起来就像是一种动态类型的解释语言。

对新手工程师来说,它很乏味,但很简单

Go 的简单性使得新手工程师可以快速使用我们的代码库,他们中的许多人以前从未使用过该语言(包括我自己)。我怀疑 Go 的设计迫使我们编写比以前更简单、更明确的代码。也就是说,简单的确会导致重复,这一点已经得到了充分的证明。截至撰写本文时,代码片段 if err != nil 在我们的代码库中出现了 2919 次。

标准库可以满足需要

Go 的标准库是一座闪亮的“灯塔”。像 bytes、encoding/json、database/sql、net/http 和 time 这样的包是全面且经过精心设计的。例如,在 Python 中,它会告诉我们第三方库(显然,三方库是好的!)采用的是 HTTP 默认缺省值。

Go 的设计显然考虑了生产代码。最引人注目的是,Assembled 有一段时间存在严重的性能问题(敲打敲打),我们可以使用 net/pprof 和 runtime/pprof 进行调试。这些功能非常强大,并且易于通过 HTTP 处理程序启用,如下所示。我唯一的遗憾是,我找到的解释该输出的最佳指南被埋没在一篇 博客文章 里了。

复制代码

superAdminMux.HandleFunc("/debug/pprof/heap",pprof.Handler("heap").ServeHTTP)
superAdminMux.HandleFunc("/debug/pprof/profile",pprof.Profile)

快速、简单的构建影响一切

Go 最好的地方在于,我们可以轻松运行 go build,并且几乎无需等待,就可以可靠地期望一个可以运行的可执行文件。在没有 IntelliJ 或 Eclipse 的情况下, Java 仍然会使编译过程痛苦不堪,更不要说从 Ruby 或 Python 开始了。

快速、简单的构建体验使许多下游任务变得更容易:

  • 我们的部署命令本质上是 git pull,然后是 go install
  • 持续集成(CI),好吧……我们可以说 Go 也没有问题

主要的困难在于,采用文件监视和循环重建的方式进行本地开发。我们有多个构建目标(例如,应用程序后端和 API),并使用 https://github.com/cespare/reflex ,但这需要一些配合 工作才能很好地 在 Mac OS X 运行。

标准格式和文档

我是否提到过,Go 显然是为专业人士打造的?

  • gofmt 处理缩进和对齐;我使用 vim-go 插件,该插件会在我们保存.go 文件时自动应用
  • 这里有一个关于 Go 文档是如何不同的雄辩解释;我最喜欢的是标准外观,位于 https://godoc.org/ 公共存储库中,它能在本地运行并能快速提取项目特定代码的事实。

Gopher :heart:

如此可爱的化身。这里有篇关于 Go gopher 起源的有趣读物: https://blog.golang.org/gopher

痛点

Go 也有令人讨厌的怪癖。其中的很多已经在其他地方被很好地记录下来了,但出于完整性的考虑,我将它们包括进来。

没有官方的包管理者故事(直到最近都没有)

从 Go 1.14(2020 年 2 月)开始,Go 模块已经准备好投入生产使用了。在此之前,这里是“荒芜的西部”:我们登陆了 dep,但没有机会迁移到模块中。 dep 是(或曾经是)一项令人钦佩的工作,但它也非常缓慢。通常的建议是将依赖项签入到存储库中(例如,在 /vendor 文件夹中),这在生产环境设置中可能并不令人欣狂。

GOPATH 让人困惑

GOPATH 目录应该魔法地包含所有代码。我认为(基于 Wiki 的推测)这与简化从远程存储库中的获取有关,例如,go get github.com/my/repo。从理论上讲这很优雅,但在实践中却是令人困惑的,因为如果我们没有将代码放在正确的位置上,就会什么都行不通。因此,Go 给我留下了非常负面的第一印象。

现在,我工作计算机上的.profile 文件只有如下内容:

复制代码

exportGOPATH=$HOME/go
exportPATH="$GOPATH/bin:$PATH"
cd$GOPATH/src/github.com/assembledhq/assembled

错误很难自省

大多数人都抱怨 Go 的错误处理太过冗长,也很难使用。在 Go 1.13(2019 年 10 月)中,添加了用于包装、拆包和比较的 优秀方法 ,但不幸的是,采用率方面我们处于落后状态。

使用 1.13 版本之前编写的代码,不会对错误进行包装,这也特别痛苦。例如,在 Google 自己的 API bindings 中,请求的底层的 HTTP 错误不会被包装,因此无法作为 googleapi.RetrieveError、公共错误接口、甚至是低级的 url.Error 进行检查。唯一的选项是字符串匹配,我们这样做,通常是为了捕获类似 invalid_grant 这样的 OAuth 错误。

例如,比较一下 Scala 中 模式匹配 是如何进行 错误处理 的。

Nil versus zero values Nil 与零值

对空值或缺省后故意将其值设置为零的值进行建模,是很乏味的。例如,在 Stripe 的 Go bindings 中可以看到 这种迁移 。在我们的代码中,我们通常会返回一个指针和错误,例如(*string,error)。通过引入非关联 nil 指针的可能性来打破类型安全。我们可以检查 res == nil 以及 err != nil,但编译器不能把我们从健忘或懒惰中拯救出来。

缺乏面向对象的表现力

Go 建议使用接口和类型嵌入来复制有用的面向对象行为,这种行为在其他语言中是自然存在的。事实证明,这些工具具有很大的限制性,在不同的情况下,我们可以偶然绕过类型系统。这导致会诱惑。

Go 社区对此进行了详细介绍。这里有一个非常不错的总结: https://blog.golang.org/why-generics

结论

最初使用 Go,我花了一些时间来热身。正如我在 GOPATH 中所描述的那样,入门有些困惑。从诸如 Ruby 和 Scala 之类的语言转换过来,也意味着需要转变思维方式(或两种)。然而,在使用该语言的两年里,我开始真正享受它的简单和明确性了。

在 Assembled 公司,该语言确实非常适合我们的用例,这是一个主要的标准 Web 应用程序。我对这个生态系统寄予厚望,感觉就像我们正在使用经过精心设计和良好维护的工具一样。因此,在快速变更代码库的同时,提供稳定服务所需的基线工作量就更少了。

原文链接:

https://wgyn.github.io/2020/04/12/reflections-on-2-years-of-golang.html