又是被 Go 语言血虐的一天。

本来一天能写完的代码，硬生生非常专注的写了一天，只完成了预期进度的 20%不到。

下班在路边等车的时候，仔细思考了下，为什么我需要要用有限状态机去管理业务动线，状态机的好处究竟是什么？又联想起之前做的leetcode 1839：longest-substring-of-all-vowels-in-order ，隐约找到了有限状态机设计的哲学。

想起以前在阿里的时候，这种事情三下五除二早就用 Java 写完几十遍了，为什么到了字节，我要开始仔细思考设计呢？固然和我不同阶段关注的点不一样，但是我能感觉到，在力排众议选择 Go 作为业务团队的项目研发语言，字节在造有史以来最大的一个轮子。

习惯了 Java 生态后，用 Go 的痛苦无处不在，时刻提醒着你，为什么没有依赖注入，为什么没有 Bean 管理，单例什么时候创建和回收，实现一个基于容器生命周期的注册简直天方夜谭，为什么没有继承，隐晦的接口实现，平铺的包结构，一页代码有半页的 if err != nil 。

吹个 Go 的拥趸们常挂在嘴边的彩虹屁，就是 Go 语言崇尚简单，所以啥都没有，说白点，就是刀耕火种，在 Java 生态中已经烂大街的编程范式，在 Go 里面就要重新实现，重新造轮子。

为什么字节要选择 Go 语言呢？

当然我不相信这是一个业务团队的领导者们经过切实调研后精心设计的选择，毕竟作出决定的 3-1，3-2，4-1 们，早已经脱离一线编码了，前两段说的痛苦，他们不可能可以切身体会。

我更倾向于另一个答案：政治正确。

在字节为什么选 Go 是政治正确呢？因为字节是工程师文化，要在传统 BAT 巨头下引领技术浪潮，Go 是其他巨头都没有采纳的方案，选择 Go，意味着在这一生态下，字节有绝对的话语权，在这一个生态下，有非常多的轮子可以造。

那造轮子有什么好处呢？

造轮子直接的好处是可以逼迫你思考，间接的好处是可以帮助你学习。

回顾前篇

轮子在 Go 生态下，会沿着 Justifiability 这条纵轴从下到上构建出来。先是最基础的 SOA 框架（基于thrift的kitex）、MQ（暂时还没有）、Consul（偏不要zk）等，而且现在连这些都谈不上好用，相信后续会有更多的想阿里内部一样丰富的中间件和技术产品涌现出来。

我一直认为作为工程的同学，在技术上，要做到无畏，没啥技术是有多难掌握不了的，只要架构设计合理，落地是不成问题的，然后这两天就感觉自己被啪啪打脸，在技术落地的成本上，切换生态后，确实需要重新校准。

虽然有点难受，不过我真的觉得这是挺好的机会。可以从头思考一些之前习以为常的设计，离开了 Java 和阿里这个长年致力于让业务工程同学越来越不会写代码的生态，重新享受钻研编码的乐趣。

也算是痛并快乐着了。