曾经使用过一段时间 Erlang,结论是:方便的地方真的方便,但麻烦的地方真的很麻烦。
最终放弃 Erlang 并不是因为社区,文档,或者开源项目的多少,而是因为语言本身。
首先是状态问题,比如要在 Erlang中操作二维地图,很多人都选择用C来实现:
Erlang 如何操作游戏中的二维地图? - 游戏引擎Erlang写无状态的代码是非常的爽的,代码就像一个个数学公式,把程序“定义” 出来,模式匹配有时也很高效。确实很适合电信系统这种请求与请求间隔离的,前后逻辑关系不大的“非状态系统”,比如 HTTP,比如棋牌或者回合制游戏。
但两个请求间如果逻辑交互很频繁,比如动作游戏,ARPG,两个角色间的交互频繁了,数据前后牵扯状态多了,用 Erlang就比较麻烦了,别人一个函数调用解决的问题,Erlang可能要几个actor之间不停的消息中转;别人改下数组的事情,Erlang可能重新构造树或者列表;别人一句话就说清了,你可能要定义一堆 “数学公式”。
Erlang是一个专业化定制程度很高的语言(非状态类电信系统,请求隔离),所以不能因为 Erlang 在有的地方比其他语言开发效率高8倍(尽管似乎号称),就觉得 Erlang在任何时候开发效率都很高,比如你在 .BAT 文件里面可以这样:
DEL d: emp*.jpg
换成 C++ 可能要写7,8行,大家就觉得 .BAT比 C++方便一样。处理文件和目录或许是,但你说用BAT写点除此之外别的东西,它就傻逼了,Erlang 也是一样,方便的地方挺方便,别扭的地方别扭死你,关键还是 Scala 和 Go 的设计充满了“妥协”,而 Erlang 里充满了 “各种原则”。在适合的领域,这些原则能让你很酸爽,而跳出那个圆圈,这些 “绝不妥协的原则” 会让你花数倍的时间和精力去完成原本很直接了当的事情。
就像:带着tt sex。
就像:穿着雨衣在跑步。
就像:批着披风再游泳。
用 golang的感觉是这样:自由
用 Erlang的感觉是这样: