2017，Go 成了日常语言
原创 · 约 8 分钟阅读 · 阅读 --

2017，Go 成了日常语言

作者: 字与码

随笔

古董级程序员，大厂出来后一直在创业公司，现在仍活跃在一线做 AI 相关的开发。这个专栏会慢慢写从 1990 年代到今天的 IT 变化，也会夹带一些自己的旧事。更完整的更新写在微信公众号「字与码」，若觉得这些回忆和观察对你有用，欢迎顺手关注。

2017 年前后，我后期基本使用 Go。

这件事放在整个专栏里看，挺有意思。1990 年代我写过汇编、Delphi、Perl；2000 年代写过 C、C++、PHP、Java、Python；到了微博后期，Go 逐渐成了日常语言。

Go 不像 C++ 那样锋利，也不像 Python 那样灵活。它甚至显得有点“笨”：语法少，抽象少，泛型迟迟没有，错误处理也很啰嗦。

但它很适合互联网后端。

朴素是一种工程能力

很多语言吸引程序员，是因为表达力强。

Go 吸引工程团队，更多是因为朴素。

代码格式统一，编译快，部署简单，静态二进制，goroutine 容易上手，标准库够用，工具链一致。一个团队里不同水平的工程师一起写服务时，这些特点很重要。

大型互联网业务里，语言不是一个人的玩具，而是团队协作工具。

表达力太强，有时会让每个人写出自己的风格；抽象太多，有时会让简单问题变得绕。Go 的克制降低了很多沟通成本。你可能会嫌它不优雅，但通常能比较快看懂别人写的服务。

Go 后端工作流

这对微服务时代尤其重要。

服务越来越多，接口越来越多，部署越来越频繁。语言本身当然不能解决架构问题，但一个稳定、简单、工具链顺手的语言，会让很多日常工作少一些摩擦。

从 C++ 到 Go 的心理落差

我很早就写 C/C++，也在 Linux 公司接触过非常有设计感的 C++ 框架。

C++ 的强大毋庸置疑。它能贴近系统，也能做高层抽象。但 C++ 的复杂度同样真实：头文件、模板、内存、编译时间、ABI、对象生命周期、并发细节，每一项都可能变成长期成本。

Go 则像是把很多选择拿走。

它不追求让你写出很漂亮的抽象，而是鼓励你把服务写清楚。网络服务、JSON、HTTP、RPC、后台任务、缓存访问、日志监控，这些后端日常工作，用 Go 写起来很直接。

这种直接，在业务压力下很有价值。

互联网后端很多时候不是在做语言艺术，而是在做可维护的线上系统。系统要能跑，要能查问题，要能扩展，要能交给新人接手。Go 在这些地方给团队省了不少力气。

微服务不是银弹

2017 年左右，微服务已经是后端工程里绕不开的话题。

把大系统拆成小服务，听起来很美：职责清楚，独立部署，团队自治，技术栈灵活。但真实情况要复杂得多。

服务拆多了，调用链会变长，问题定位会变难，数据一致性会变复杂，部署和监控也会变重。一个单体系统里的函数调用，拆成服务后就变成网络调用、超时、重试、降级、熔断、版本兼容。

Go 适合写微服务，但它不会替你设计好微服务。

这也是我后来一直强调的：工具解决工具层的问题，架构问题仍然要靠工程判断。什么时候拆，拆到什么粒度，接口如何演进，失败如何处理，数据归谁管理，这些都不是换语言能自动解决的。

工程效率比语言信仰重要

回顾这些年，我用过很多语言。每个阶段都有当时的“最好选择”。

Delphi 适合快速做桌面和数据库应用，Perl 适合那个年代的脚本和文本处理，PHP 撑起过大量 Web，Java 在平台和大数据里很强，Python 做工具和数据非常顺手，C/C++ 仍然是系统软件和高性能场景的基础。

Go 在 2017 年前后对我最重要的意义，是它把后端工程的日常摩擦降了下来。

这不是语言信仰，而是工程效率。

一个程序员如果经历过多种技术周期，会慢慢少一些争论“哪门语言最好”的兴趣。更实际的问题是：团队是谁，业务是什么，系统规模多大，维护周期多长，线上风险在哪里，工具链能不能支撑。

2017 年的 Go，正好回答了很多互联网后端团队的现实问题。

下一年，短视频和推荐会更明显地改变流量格局。微博和今日头条之间的差距，也会被越来越多地看见。

2017 年 IT 大事记

  • Go 在后端和云原生生态中扩大影响。 Go 的编译速度、静态二进制、并发模型和工具链，让它成为很多互联网后端和基础设施团队的务实选择。
  • Transformer 架构提出。 论文《Attention Is All You Need》提出 Transformer。它当时看起来是机器翻译和序列建模的重要进展，后来却成为大模型时代最关键的技术底座之一。
  • 微服务成为高频话题。 微服务、容器、服务治理、监控和链路追踪成为后端工程中的高频主题。系统复杂度从单体内部转移到服务之间。
  • 云原生工程继续铺开。 Kubernetes、容器镜像、CI/CD 和基础设施自动化逐渐改变服务交付方式。部署和运维开始更多被平台化吸收。
  • 团队协作影响语言选择。 语言选择不再只是个人偏好。可读性、工具链、部署方式、线上维护成本和团队成员水平，都会影响一门语言能否在组织里长期使用。

参考资料

本专栏其他文章

查看专栏「我与 IT 这三十年」全部文章