速度变身高大上程序员快来学Erlang吧！参与讨论获好礼（获奖名单已公布-2014-8-29）

crazyhadoop

回复 24# cokeboL


    换个思路学习一下也不错的，你可以感受一下函数式语言的姿势！

cokeboL

回复 31# crazyhadoop


    恩恩，以后有时间再研究，我先面向产品和职业方向学习

bluejing0

Erlang本身的一些机制的不足
1.        运行时record 的问题，
Record 在erlang中并不是一个运行时可见的数据结构。代码中所有对record的变量的赋值，读取等操作全部会转化为对tuple的element的操作。这种形式带来了无穷无尽的麻烦：主要是在产品升级的时候。我们的电信产品一般会要求6个9，即：99.9999%的稳定性，和0 downtime。即：升级的过程中不允许有电话打不通的时间。如果某个record在版本升级中结构变化了，而不允许有downtime意味着大量的进程要有能力处理旧的和新的record，一不小心就crash给你看。
这个问题我跟OTP team讨论过无数次了，他们也没有很强的想法在这上面，beam文件本身已经包含了record的相关信息不知道为什么不肯做一个简单的实现。
现在我们的实现方法是在运行时反编译自己，获取record的信息进行操作。但这个要求编译的时候要带debug作息，而且cookie一旦泄漏，源代码很容易被反编译出来。
在OTP R17中引入了一个新的数据类型，叫做MAP，类似于JSON的数据结构，它与record相比做了质的变化：运行时可见了，并且可随意添加成员变量。这无疑是对record这种旧的数据结构的另外一种演化方向。我很喜欢这种变化。但是我们同时也不得不考虑软件维护的成本：不可能仅仅是为了使用这种数据结构而把原来的上百W行代码重写。所以个人而言，我还是希望能有一个运行行的record，例如把record转化为map，并且兼容对record的操作方式，并在几个release内慢慢淘汰record这种数据结构。
2.        字符串的处理，
字符串在erlang中一直是个弱点。
包括正则表达式。在很多语言中正则表达式本身是做为一种特殊的数据类型存在的，比如用//包住，在erlang中，RE本身是做为字符串处理的，而字符串和RE都有转义的问题，要匹配一些特殊字符就要进行多次转义，非常恶心，比如用"\\\"去匹配 "\"。如果要匹配多个这样的字符，那写出来的正则表达式简直无法入眼。
另外，字符串的处理效率也是个问题。字符串在erlang本来是以Lists存在的，虽然有个string的库，不管说它丰富不丰富，效率就是个问题。

3.        运行效率的问题，虽然R17已经有了LLVM backend，但是效率还是不够。而且HIPE本身存在的问题也很多，有很多莫名其妙的bug。而HIPE本身年纪太大， 很多想法已经太out。
LLVM的效率的确不如HIPE，在LLVM的performance test中可以看其效率与原来的HIPE基本持平。但是好处是LLVM是开源的工具链，其做为backend稳定性应该会比HIPE强。在乌不撒拉大学的原来的HIPE主页上，感觉终于把HIPE赶走了可以松一口气了。R17的release notes中也认为LLVM HIPE可以做production usage.

4.        mnesia问题。mnesia效率实在太差，差的都不想吐嘈了，现在完全成为了系统的瓶颈。
Mnesia本身一般不会存储用户数据，一般只是一些配置数据。在我们的产品中大约有几百张表，每个表一般只有几条到几十条不超过上百条记录。即便这样，mnesia已然不堪重负，严重的成为了系统的瓶颈。
5.        同时Mnesia为SNMP做了很多优化，但是这些优化很多时候限定了mnesia data schema本身，这种绑定有时候不但不会带来收益，会带来很多问题。
6.        调试工具实在太烂，有时候很容易把自己卡死。我后来不得不改了他们的源代码，没事别乱打印，wx太慢，一打印大数据结构就卡死了。
如果有一个更好的调试的库就更好了。
7.        dbg:tracer只能trace MFA 或者msg, 远远不到完善的地步。
需要一个更好的dbg的库。
8.        to_erl环境变量的问题，跟OTP的人们说过，他们坚决不改。
但是其实这个很简单，可以考虑做个工具，在用户用to_erl连接到VM的时候把用户的一个ENV（如display） apply一下，只要不影响运行中的程序就可以了。
9.        两个site连接起来之后不能立即通信，要sleep一会儿。
我搜索了好久，仍然搞不清楚erlang是如何解析和连接node()的。
10.        文档不健全，很多文档语焉不详，要必须跟OTP的人聊过或看过代码之后才明白。 从如描述smp的那一大段。
11.        没有bench mark的工具
12.         OTP升级不够平滑。每次换OTP都心惊胆颤。

q1208c

回复 33# bluejing0

这位兄弟看来是真正的高手, 原来erlang中有这么多问题.

对于 OTP的升级, 小弟虽然没有在生产中用过, 但发现每次更新
都有一堆新的问题. 真不敢想, 这货也能做到 7个9 . 不知道那
要多少个节点才顶住得. 还必须有非常良好的架构.


不过, 对于 record, 小弟以为, 为什么要去动record的结构呢?
在record的一个字段里动不是更好? 有点类似 数据库 的一维表.


小弟新学, 还没入门, 还请兄弟多多指点.

bluejing0

to: crazyhadoop
是的。

bluejing0

回复 34# q1208c


    record就跟class一要，偶尔添加几个成员是很正常的操作。在生产环境中真是天天见。

q1208c

回复 36# bluejing0

我觉得这个问题就跟数据库一样. 经常有人要增加字段. 但谁都知道, 对于一张很大的表, 如果增加字段. 是个很耗时的操作, 有时候, 还有风险.


   

shenlanyouyu

Erlang不懂，顶一下活动。

it5186

帮顶！在学Erlang程序设计——PDF的，书可以给一本吗？

yqw1122

去年的一个偶然机会，在网上看到了erlang的介绍， 很感兴趣。
Erlang具有多个进程之间不用“锁”的特性，这个是传统的c/c++/java等不具备的。
Erlang是我想利用空闲时间学习的一门计算机语言，不一定可以用的到，但是它的思想让我耳目一新！
很遗憾的是，现在很少有公司用Erlang作为开发语言，我的目标是哪天可以自己用erlang写出一个高性能的服务器程序，哈哈。。