全世界只有我们是正确的，其他的全错了。我们(Erlang程序员)找到了症结并正确的解决了问题，所有的其他人(非Erlang人)都找错了方向，解决了错误的问题。
全世界其他人想解决的问题是如何让现存的程序能并行执行。2004年之前，摩尔定律一直有效。每年我们的程序执行都会变得更快，我们不需要成为一个优秀的程序员，我们不需要掌握更优化的算法就能让程序一年比一年更快。
芯片越来越大，时钟速度越来越快，程序运行速度越来越快，每年大概以15%幅度的性能提升。
到了2004年，这些现象终止了。芯片已经足够大，时钟的速率已经快到在一个时钟周期内时钟脉冲不能到达芯片的所有部分。电路设计开始改变。多核处理器出现。
从2004年开始，芯片的体积仍然在增大，但时钟的速率开始变小，每个芯片上的CPU数量开始增加。我们从每一个芯片只有一个超级处理器的时代进入到每个芯片有多个速度较慢、性能较弱的多核处理器时代。
由此开始，顺序执行的程序显得越来越慢，一年慢过一年，而并行执行的程序开始变得越来越快。
问题是，根本没有并行执行的程序，有也是极少。
而Erlang是一种具有并发特征的编程语言，所以Erlang程序本质上在具有并行能力的计算机上运行时要比其它程序都快的多。而唯一能阻挡它运行的更快的问题就是Erlang程序中可能存在一些必须顺序执行的瓶颈。
并行程序中有需要顺序执行的部分，这正应验了Amdahl定律。
假设你的程序中有10%是需要顺序执行的(其余部分可以并行)，可以并行的部分的执行时间可以压缩近似0——只要有足够的可以并行的处理器。但顺序执行部分的时间无法缩减。
如果程序中含有10%的需要顺序执行的代码，你的程序执行速度最高能提高10倍。其中1/10的程序的速度永远无法提高，其它9/10的程序的执行时间可以缩减至接近0。
所以，对于Erlang程序员来说，提高他们的程序的运行速度的技巧就是找出代码中需要顺序执行的部分。
而对于任何对于其他编写顺序执行程序的程序员来说，提高他们程序速度的方法是找出他们程序中可以并行执行的部分。
让串行程序自动并行化的征途铺满荆棘，无法走通。(并不完全是这样，在某些特殊环境中是可以实现的，但绝非易事)。
现在的数据中心了都排满了酷炫的新型计算机，某些顶级的配置里拥有多达24核。但它们的性能呢？这些酷炫的新机器能快24倍吗？
对某些程序来说是的，但对大多数程序来说不是。对大多数程序来说24个CPU中只有一个被利用。CPU的低利用率成了一个严重的问题。这点正印证了Alexander Gounares
Brilliant在Erlang factory谈到的问题。
Alexander的演讲让我们隐约看到了未来。他开创concurix让我们看到了未来的方向。他们正在开发工具能自动找出Erlang代码中需要顺序执行的瓶颈。
Concurix使用这些工具来发现Erlang虚拟机中的瓶颈，在他们的测试中显示了惊人的结果。他们找到了一个图片处理应用中的瓶颈，它是zlib库中的一个程序锁，是用C写成的。他们用Erlang重写了它，用Erlang替换了C代码。
这真是不可思议，C程序本应更快，事实也是，但它却有个同步锁。Erlang程序相比之下要慢，但没有状态锁，这赋予了它提升能力的机会。去掉了C代码后，用Erlang写成的图片处理应用比原始的C程序快了很多。
我很吃惊——惊奇于这样的好东西的出现。
当Alexander在Erlang factory的演讲视频出来之后，你们观看时准备好惊奇吧。这是未来，未来就在下周旧金山。
不错的广告
状态锁确实是个问题。虽然这篇文章有广告之嫌，但确实切中了其他语言的痛处。
什么时候需要并行运行？
好吧，你赢了。
dont kidding, do you know google-go?
我用PLINQ，效果也非常好
node.js如何？
node.js的并发和erlang比…那就是小巫见大巫了，360度被完爆。
哈哈，是的，我也是越来越喜欢Erlang了
井底之蛙，没有调查就没有发言权
我用C/C++可以针对硬件写线程、进程甚至GPGPU不同方式的并行程序，充分利用硬件系统，只不过问题变成找出那9成可以并行的代码，与找出1成不可并行的代码有啥不同，何必沉沦于Erlang的语言糖果？相比之下，我倒是更看好逻辑编程语言，节省开发时间，只要不是做大规模的科学技术，一般交互程序渐渐地已经不需要格外看重性能了
好一个典型的“沉迷于现状”和“老子最牛你们都是渣”的表现
erlang的好处是有一套工业级的架构来保证写出来的代码在保证稳定的前提下尽量大的去并发，类似supervisor，gen_server这中东东每次写C都要自己弄一套，这不是有病么，还有我发现你完全没理解并发和并行的概念。纯粹不懂装懂来着。你的充分利用硬件系统用在大数据计算方面还凑或，用在IM方面你试试。
语言从来就不是关键，纠结于到底是erlang还是c/c++还是node.js这本身就是无意义的。
文章自己也说了，关键是要实现的逻辑有多少部分能够被并行的执行。真的能够完全被并行执行的东西，早就已经被人实现了，比如图形渲染，现在的3D显示芯片已经有数千个流处理器来执行完全并行的着色操作。
从顺序逻辑中找出可以并行执行的部分和从并行逻辑中找出只能顺序执行的部分这两种方式并没有本质区别，只是人的选择的思维角度问题。但是一个逻辑问题的解决方案中，最终有多少比例是无法并行化只能顺序执行的，这个是确定，跟语言也没有关系。在确定了这些顺序逻辑之后，剩下的就是设计算法，然后实现而已
SB，你知道函数式语言有多少么，你知道并发的模型有多少么，你知道哪些编程语言实现了哪些并发模型么？
呸