首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

我使用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处理程序启用,如下所示。我唯一的遗憾是,我找到的解释该输出的最佳指南被埋没在一篇博客文章里了。

代码语言:javascript
复制
  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 ❤️

如此可爱的化身。这里有篇关于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文件只有如下内容:

代码语言:javascript
复制
  export GOPATH=$HOME/go
  export PATH="$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

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/yDMrvVr1IJAAih3eh5fW
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券