作者: BigLoser 访问次数: 698 创建时间: 2020-05-01 16:03:28 更新时间: 2024-05-08 14:15:36
过去两年来,我就职于 Assembled ,一直使用 Go 工作。自公司成立以来,Go 就一直是我们的主要后端语言。在我之前的工作中,我混合着使用 Ruby 和 Scala,所以肯定有过一段适应期。总体而言,我发现 Go 的表现基本上与广告宣传的一样:尽管有些怪异,但它非常适合专业工作。
Assembled 是客户支持团队用来管理人员配备和分析的 Web 应用程序。从架构的角度来看,它是一个标准的 Web 应用程序:React 前端通过内部 HTTP API 访问 Go 后端,后者反过来访问 PostgreSQL 数据库。
也就是说,有几个特定的应用程序,我们也必须对其进行优化:
我们构建 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 处理程序启用,如下所示。我唯一的遗憾是,我找到的解释该输出的最佳指南被埋没在一篇博客文章里了。
|
|
|
Go 最好的地方在于,我们可以轻松运行 go build,并且几乎无需等待,就可以可靠地期望一个可以运行的可执行文件。在没有 IntelliJ 或 Eclipse 的情况下, Java 仍然会使编译过程痛苦不堪,更不要说从 Ruby 或 Python 开始了。
快速、简单的构建体验使许多下游任务变得更容易:
主要的困难在于,采用文件监视和循环重建的方式进行本地开发。我们有多个构建目标(例如,应用程序后端和 API),并使用 https://github.com/cespare/reflex ,但这需要一些配合工作才能很好地在 Mac OS X 运行。
我是否提到过,Go 显然是为专业人士打造的?
如此可爱的化身。这里有篇关于 Go gopher 起源的有趣读物: https://blog.golang.org/gopher
Go 也有令人讨厌的怪癖。其中的很多已经在其他地方被很好地记录下来了,但出于完整性的考虑,我将它们包括进来。
从 Go 1.14(2020 年 2 月)开始,Go 模块已经准备好投入生产使用了。在此之前,这里是“荒芜的西部”:我们登陆了 dep,但没有机会迁移到模块中。 dep 是(或曾经是)一项令人钦佩的工作,但它也非常缓慢。通常的建议是将依赖项签入到存储库中(例如,在 /vendor 文件夹中),这在生产环境设置中可能并不令人欣狂。
GOPATH 目录应该魔法地包含所有代码。我认为(基于 Wiki 的推测)这与简化从远程存储库中的获取有关,例如,go get github.com/my/repo。从理论上讲这很优雅,但在实践中却是令人困惑的,因为如果我们没有将代码放在正确的位置上,就会什么都行不通。因此,Go 给我留下了非常负面的第一印象。
现在,我工作计算机上的.profile 文件只有如下内容:
|
|
|
|
|
大多数人都抱怨 Go 的错误处理太过冗长,也很难使用。在 Go 1.13(2019 年 10 月)中,添加了用于包装、拆包和比较的优秀方法,但不幸的是,采用率方面我们处于落后状态。
使用 1.13 版本之前编写的代码,不会对错误进行包装,这也特别痛苦。例如,在 Google 自己的 API bindings 中,请求的底层的 HTTP 错误不会被包装,因此无法作为 googleapi.RetrieveError、公共错误接口、甚至是低级的 url.Error 进行检查。唯一的选项是字符串匹配,我们这样做,通常是为了捕获类似 invalid_grant 这样的 OAuth 错误。
例如,比较一下 Scala 中模式匹配是如何进行错误处理的。
对空值或缺省后故意将其值设置为零的值进行建模,是很乏味的。例如,在 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
语言: zh-CN
翻译人员:
原作者:
转载地址:
源网址: https://www.infoq.cn/article/yDMrvVr1IJAAih3eh5fW
版权: 本站所有内容, 版权归原作者所有。发表原创内容将会获得现金奖励, 并且随着时间倍数增长, 请了解我们的内容奖励计划。