关于erlang在中国发展的一点个人看法

“非工业主流”编程语言

所以为什么是“非工业主流”编程语言。

我不知道如何下一个严格的定义。简单地说，就是不被绝大多数程序员所使用的编程语言。

看看tiobe的语言排行榜，你可以了解我在讲什么。Java、C、VB、C++和PHP占据了70%的份额，它们是当之无愧的工业主流语言。而 Ruby尽管连连升级，排名13位，份额也不过是0.804%，Lisp/Scheme连连下挫，目前仅为0.586%，如果你仔细寻找，在The Next 50 Programming Languages的标题下，Erlang,Lua,Scala缩在角落里，这些“可怜”的语言当然是非主流的。自然，你不不太可能认为PL/SQL 、 Visual FoxPro、 VB.NET和Lisp、Ruby、Erlang、Lua是同类，我也这样想。

或许你和我曾经或正在感到非常振奋，那些你我日常的编程语言高居前列，并引以为豪。但是事情并不是完全象我们想像的一样。

编写程序需要乐趣，很难说工业主流语言能够提供你更多的乐趣。我所知道的很多程序员在白天忙乎完手上的Java,C++工作后，晚上会带着一种神秘的快感摸索一些可能自己一辈子也不会用于谋生的语言。

当然，这可能是厌倦造成的，但是当你发现一个苦思冥想、或者需要n多语言规则、框架、n多所谓的高深理论解决的问题，在另外一种语言中是最最简单的一个特性，恐怕这种懊恼的感觉不是可以轻易描述的。譬如，当你天天为C/C++的内存释放绞尽脑汁的时候，当你为垃圾收集在Java的出现而欢呼的时候，你是否知道30年前，那已经是Lisp的一个标准构造了。当你天天面对着无穷无尽的并发要求，纠缠不清的哲学家吃面头皮发麻的时候，你可能很想知道Erlang 20年前就让极大规模的并发和可靠性处理变成小事一桩。

编写程序还需要创造价值，一个非凡的产品在获得巨大利润的同时，更会带来一种心底而生的自豪感。如果要担心工作的问题，那么主流语言是你必不可少的谋生工具。但是如果你从头建立一个公司，希望用有限的资源和人力制造出强有力的产品，一个与众不同的产品，那么你需要秘密武器，这些武器是什么呢？

当然可以有很多，但其中最有杀伤力的武器之一无疑是编程语言－－高生产力，适合某一领域的非工业主流语言。这种例子并不罕见，例如：

    * Beating the Averages
    * Making Money from Erlang
    * google

也许，你喜爱的语言被成千上万的人使用并不是那么令人自豪的事情；自私一点地说，缺乏同伴或许能够带来更多的乐趣和财富

编写可靠软件－面对不可避免的错误

学习一种新语言的目的是什么？

最重要的是能够从新的语言中吸收到新的营养，从不同的角度去理解我们所碰到的问题，以及新的解决问题方式。至少不至于坐井观天。

或许你认为理想上经过严格测试的软件是不应该有Bug的，而当Bug作恶的时候你会产生罪恶感，你觉得总有那么一条道路可以通向完美的零缺陷之路，你自责、困扰。但你是否曾经反过来想想，这种理想是永远达不到的，但是如果我们承认系统、软件是包含错误的，我们是不是无能为力了？

这两年来我做的一些程序和以往的软件相比有一点很大的不同，那就是经常需要和硬件打交道。我们经常碰到的一个问题是在很多情况下，譬如温度过高、或者运行时间过长、或者磁盘读写、删除次数太多的情况下，DSP会暂时停止运行，或者磁盘会损坏。这个时候，你能干什么？假装这些事情不会发生？

有些时候也并不完全是硬件的问题，在如今高度紧张的竞争环境下，我们的客户需求变更完成时间通常以天或者周为单位，如此的速度去响应你的客户，你能保证你的代码没有任何问题？

没有人能够保证，但是这个时候，你还必须做到这样的系统是能够可靠运行的，就拿我们的其中一个软件来说，虽然本身价值不高，但是它可能牵涉到大量的金钱、甚至是人的生命。

为了解决这些问题，在某些关键的位置，工程人员必须在机器上插入硬件狗，在机器停止响应的时候自动重新启动机器。但是某些时候机器本身是没有问题的，而是系统或者软件的问题，例如DSP因长时间运行停止运作，或者程序本身产生错误，所以我们需要软件狗，一个守护进程，监视系统的运行状态，并在出现异常的情况下重启系统。

然而，这样还是不够的，某些时候，整个系统的运行是正常的，只不过某些模块会出现问题，因此，我们进一步把整个系统划分为几个重要的模块，单独的进程运行这些模块，一个比较完备的守护进程管理这些模块之间的依赖关系、它们的启动、状态监视以及出现异常的情况下按照某种顺序重新启动。

这样的需求和实现出现在我们一个小小的产品中，但很快发展到我们所有的软件中。例如，视频编解码通常需要大量的CPU，而在CPU 非常紧张的情况下或者某些时候编码器网络传输的流数据不正常，解码器通常会出现异常的情况，轻则停止解码，重则退出系统。而在监控大量视频图像的情况下，工作人员或许根本无法注意到哪一路图像出现异常。所以，客户的要求是不管因为网络、编解码软件或者其他什么原因，必须保证24小时永不停止的图像显示（如果能够自动恢复的话），在我们流媒体、集中存储系统中也存在着同样的需求。

因此，我们必须假设系统、程序是包含错误的，在这样的情况下我们如何编写可靠的软件？

我们用自己的守护系统来应对这个问题，但是并不是那么系统、完备和彻底。

而这也是Erlang要解决的问题，通过编程语言、通过库、通过良好的系统原则来构造可靠的强壮的系统，如果我能够早一年看到，或许就会少走许多弯路，能走得更好。