2、erlang是 天生的并发语言 ： erlang的并发特性是语言级别的，从开发伊始就采用了CSP并发模式, 以进程为单位，进程间没有共享内存，变量不可变的实现方式保证了无锁的并发模型，因此也是异常高效的，换句话说：你只要像平常一样写代码就能并发，完全不用操心任何底层实现，你的代码能完美的并行运行在多核服务器上，如果你能写出漂亮的并发级别的算法和代码(尽量少的顺序代码)，那在32核机器上就能跑出32倍性能！！！！ Go 语言的并发模型也是取经于Erlang,但是我认为Erlang的并发模型更优秀，因为进程间完全没有共享内存，完全无锁。
3、由于Erlang和Go都是非常棒的语言，这里就出现一个问题：二选其一还是物尽其用？经过深思熟虑后，我和团队选择了后者。
个人建议学习Golang，主要原因如下：
Erlang的硬伤在于代码的可读性、表现力。为什么说是硬伤？ 因为对一门语言来说，语法是不大可能会大幅度变更的， 而且不会出现大的变化；
Erlang的软肋在于高质量的库少。尽管有不少杀手级应用， 同样Go在这方面也是软肋， 这一点对于一个不到五年的语言有情可原， 但对于一个20多年的语言是不是有点说不过去；
Erlang不合群。 这主要体现在跟其他语言的交互性上， 当然这也有深层次的原因， Erlang本身有自己的哲学， 如出错恢复机制， 你融入一个其他语言的东西进去， 这帐就不好算，就好比你硬要让一个喝咖啡的跟一个吃大蒜的坐在一起， 总之你写一个Erlang的port远远比Go复杂， 甚至比Python/Java还要复杂， 这就造成了Erlang在底层编程上效果不是很好， 没法利用linux已有的很多优秀成果，我一直认为Erlang的什么的mysql/pg/oracle驱动都没有必要存在， Erlang一定是一个self-container应用， 你只要用到了其他东西， 根据木桶理论， 你就不敢号称9个9，以系统的眼光看问题， 我觉得一个系统的鲁棒性不能依赖于某一组件， 这也是为什么爱立信本身的Erlang应用并不广泛；
Erlang的的报错信息太让人纠结了。在Erlang中一切都是并行的， 所以它根本不care是物理哪一行出错， 只跟Actor绑定， 然后告诉你Actor的ID和出错代号。这一点Golang就做了很好的折中， 不需要并行的时候你老老实实的写串行代码， 需要并行的时候也有较复杂的机制来应对， 合乎情理。
1. 对锁的态度不同2. 对异步IO的态度不同
3. 消息机制不同
4. Erlang对锁非常反感，认为变量不可变可以很大程度避免锁而Golang的观点是锁确实有很大的负担，但锁基本上是无法避免的，一旦有人共享状态并且互相抢占去改变他，这时候锁是必须存在的。
Erlang服务器是单进程的，是逻辑上没有并发的东西，一个Process就是一个执行体，所以Erlang的服务器和Golang的服务器是不一样的，Golang的服务器是多进程的一起构成的一个服务器，每个请求建立一个独立的进程。
而Erlang不同，一个服务器就是一个单进程的，所以并发的请求都进入到了进程的邮箱，然后这个服务器从进程邮箱里取邮件处理，Erlang的服务器并没有并发的请求，所以不需要锁。
