在某乎上看到了这个问题, 还是挺故意思的. 撕哪个措辞最好, 险些是工程师当中最好的引战题目了. 本日我只想谈谈我是怎么看待 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 也并没以为自己亏损. 这不, 还能在这里水一篇文章呢.
