在某乎上看到了这个问题, 还是挺有意思的. 撕哪个语言最好, 几乎是工程师当中最好的引战题目了. 今天我只想谈谈我是怎么看待 Go 的, 以及我走的一些弯路.

我是 2010 年在学校的时候了解到 Go 语言的. 当时的 Go 语言还是一塌糊涂, STW GC 是大家嘲讽 Go 语言的最佳标靶. 只要黑一句, Go 粉基本被噎得说不出话来.

我当时正想储备一门带并发编程模型的语言. 因为觉得未来 CPU 主频不再增长的情况下, 带并发编程模型的语言肯定是未来的主流. 是共享内存型语言强有力的竞争对手.

候选名单如下:

Erlang, Golang, Scala 搭配 Akka.

首先 Scala 被我排除掉了, 因为 Akka 的实现我觉得并不好, 而且当时 Scala 并没有本质上的重量级应用 ( Spark 虽然在 2010 年开源了, 但是真正流行起来要到2012年后了 ). 其次就是 Go 和 Erlang 了.

当时我对 Erlang 非常痴迷, 因为 Erlang 是唯一一个实现了软实时调度器的编程语言. 这意味着这东西可以直接用来写电话交换机 ( 当然 Erlang 诞生之初也是为了这个目标而存在的 ), 而如果要用Go来写电话交换机, 很可能会电话打着打着, 碰到了 STW GC, 然后你就听不到电话对面在讲什么了 ( 这也是为什么后来 WhatsApp 用了 Erlang, 50 个工程师写出了支撑 9 亿用户的系统 ).

而且, Erlang 实现的系统, 做到了 9 个 9 的可用性. 这是什么概念? 这意味着全年停机时间不超过 31.56 毫秒. 几乎就是不会停机了. 阿里云都只能说自己的可靠性 6 个 9, AWS 的可用性只有 99.95%. 意味着每年要停机 4.5 小时左右.

Erlang 另外一个设计的好的地方是, 它本身的 runtime 与其说是虚拟机, 不如说是操作系统, 是个运行时容器. 要知道 BEAM ( Erlang 虚拟机的名称 ) 在1992年就被实现了. 而 Docker 2013 年才出现. 这是多么超前的理念.

于是我义无反顾的学了 Erlang, 而 Golang 我只是看了看语法, 写了几个 demo, 观望了下.

时间来到了 2012年, 我去 360 搜索实习. 我被分配的一个任务就是写一个监控程序, 实时收集并展示 nginx 的连接数等状态, 做数据可视化供运维工程师调度机器参考. 机器的数量非常多, 并且要实时展示, 这算是个难点. 我立刻想到了用 Erlang 写, 这简直是为 Erlang 量身定做的场景.

我写完了, 并且顺利的实现了功能. 这时候收到的反馈是, 写得很棒, 但是公司没有用 Erlang 的工程师, 没办法维护, 所以在建议下我又用 Node.js 的 websocket 和 Redis 的订阅机制实现了个伪实时的监控系统... 这是我第一次, 也是最后一次用 Erlang 给企业写应用.

是的, Erlang 输在了这里. Erlang 的发明者 Joe Armstrong 有一篇文章 solving-the-wrong-problem 开头第一句就说了这么一句话:

We're right and the rest of the world is wrong. We (that is Erlang folks) are solving the right problem, the rest of the world (non Erlang people) are solving the wrong problem.

现在来看, 这句话简直太中二了, 大意就是, 错的不是我, 是世界.

Erlang 为什么没有在 CPU 主频无法继续提升, 而核心数猛增的这么好的生态下火起来. 这个问题其实大佬早就说过了. Erlang 也不是唯一一个倒下去的例子. Richard P. Gabriel ( Common Lisp的发明者之一 ) 在这篇文章中 The Rise of Worse is Better 很好地阐述了为什么 Lisp 会没人用, 这个道理同样适用于 Erlang 身上.

简单来讲就是, Erlang 太好了, 为了完美的解决问题导致设计的很难学很难使用. 曲高和寡. 而那些简单好用的垃圾, 才能流行起来.

很合理, 这个道理再简单不过了. 这也是为什么大家不去看书, 而是喜欢去听喜马拉雅听, 喜欢去看知乎, 喜欢去看掘金, 喜欢这些被咀嚼一遍的东西, 觉得学到了知识. 因为对大家来说, 看书太难了, 太痛苦了.

但当时我年轻啊, 觉得那好办, 我这次选个最简单的, 于是我又跟风学了 Lua (openresty). 这个倒是很简单, 我是看左耳朵耗子老师那篇 LUA简明教程入门的. 我的确是在厕所蹲坑的时间就学会了, 不到 1 小时 ( 有 JavaScript 经验的同学会更快一些 ). 然后写了很多个支持单机 10 万+级别并发的应用 ( 比如熊猫TV直播间的右侧礼物排行榜, 比如掘金的全局数据缓存等等 ).

但 Golang 也有了类似解决方案. fasthttp 作为 Go 的代表型高性能WEB框架, 轻松也可以支持 10 万级别的并发.

是时间不等人. Golang 在 10 年时间, 成为了怪物. 不但 STW GC 的问题解决了 ( 当然还是比不上软实时的 GC 那么平滑 ), 而且有了 kubernetes 这样的可怕的杀手锏. 也许有同学不理解 kubernetes 的可怕. 未来, 大家写的程序很可能既不是直接运行在物理机上, 也不是运行在 Xen, VMWare 等虚拟机上, 而是都会运行在 Docker 上, 由 kubernetes 进行调度. 甚至连选择的权利都没有 ( 不相信的同学可以问问在大厂的同学, 他们有自己部署目标机的 root 权限么 ).

看到这里, 是不是很熟悉? Erlang 早都实现了这一切, 甚至调度粒度更细, Erlang 实现了内置进程 ( 类似 goroutine ) 级别的调度. 而 Golang 的 goroutine 可不能跨 Docker 调度吧? ( 虽说接个网络通信模拟下也能实现类似的东西 ) . Erlang 提出了 Let it Crash 的概念. 现在看看 kubernetes 疯狂重启你的 docker pod, 是不是似曾相识?

openresty 也说明明是我先的 ( 白学现场 ), openresty 诞生之初, 能轻松支持 10 万级别并发访问的WEB框架屈指可数. 但现在 Golang 也可以了. 甚至更好 ( 少背了个 nginx 这么大个包袱 ).

读到这里, 你也许会问, 你这么作死, 每次几乎都选错了, 怎么还能混口饭吃? 那我只能说, 我编程的入门语言是 PHP, 这玩意比 Golang 还 New Jersey Style. 让我能找到工作的也是 PHP. 而我却在别的语言上持续作死. ......哈哈哈哈...... 这还真是悲哀.

有正在用 PHP 同学也许会问, 那么学 swoole 合适吗? 我的建议是. 都是成年人了, 不要做选择, 全都要. 无论是 swoole, fasthttp, netty, 都值得你看. 我学了 Erlang 也并没觉得自己吃亏. 这不, 还能在这里水一篇文章呢.