1、大家听说Erlang，往往是因为其对高并发的良好支持。其实，Erlang的核心特征是容错，从某种程度上讲，并发只是容错这个约束下的一个副产品。容错是Erlang语言的DNA，也是和其他所有编程语言的本质区别所在。
2、从某种意义上讲，Erlang不仅是一门编程语言，更是一个系统平台。它不仅提供了开发阶段需要的支持，更提供了其他语言所没有的运行阶段的强大支持。其实，在静态检查和测试阶段发现的问题往往都是些“不那么有趣”的问题，那些逃逸出来的bug才是真正难对付的。特别是对于涉及并发和分布式的bug，往往难以通过静态检查和测试发现，并且传统的调试1 借助操作系统的进程也可以做到运行时的错误隔离，不过粒度太大，也过于重量。 2 为了能够做到跨OS的高效调度，Erlang放弃了基于时间片，采用了基于reduction的方式。几乎在系统的每个地方都会进行reduction计数，来达到公平调度的目的。手段也无法奏效3。而Erlang则提供了强大的运行时问题诊断、调试、解决手段。使用Erlang的remote shell、tracing、自省机制以及强大的并发和容错支持，我们可以在系统工作时，深入到系统内部，进行问题诊断、跟踪和修正。甚至在需要时在线对其进行“高侵入性”的外科手术。
3、对于Erlang存在的问题5，提得最多的有两个：一个是缺乏静态类型支持，另一个是性能问题。Erlang是动态类型语言，往往会被认为不适合构架大型的系统。我自己也非常喜欢静态类型。一个强大的静态类型系统不但能够大大提升代码的可读性，而且还为我们提供了一个在逻辑层面进行思考、设计的强大框架，另外还可以让编译器、IDE等获取更深入的代码结构和语义信息从而提供更高级的静态分析支持。
4、不过，在构建大型系统方面，我有些不同看法6。如果说互联网是目前最庞大的系统，相信没有人会反对。那么这个如此庞大的系统能构建起来的原因是什么呢？显然不是因为静态类型，根本原因在于系统的组织和交互方式。互联网中的每个部件都是彼此间隔离的实体，通过定义良好的协议相互通信，一个部件的失效不会导致其他部件出现问题。这种方式和Erlang的设计哲学是同构的。每个Erlang系统都是一个小型的互联网系统，每个进程对应一台主机，进程间的消息对应协议，一个进程的崩溃不会影响其他进程……。Erlang所推崇的设计哲学：crash‐oriented以及protocol‐oriented，是架构大型系统的最佳方式7。当然现在，你鱼和熊掌可以兼得，Erlang已经支持丰富的静态类型定义和标注功能8，并且可以通过Dialyzer工具进行类型推导和静态检查。
5、再来说说性能问题。在计算密集型领域，Erlang确实性能不高9。因此，如果你要编写的是需要大量计算的工具程序，那么Erlang是不适合的。不过，如果说涉及计算的部分只是系统中的一个局部模块，而亟需解决的是一些更困难的系统层面的设计问题：并发、分布式、伸缩、容错、短响应时间、在线升级以及调试运维等等，那么Erlang则是最佳选择。此时，可以用Erlang作为工具来解决这些系统层面的难题，局部的计算热点可以用其他语言（比如C语言）甚至硬件来完成。Erlang提供了多种和其他语言以及硬件集成的方法，非常方便，可以根据自己的需要（安全性、性能）进行选择
6、和大多数编程语言相比，Erlang在如何处理错误方面显得非常独特。我们一般会认为，语言、编程环境以及方法论都应该尽其所能来防止错误出现。所有会导致运行时错误的东西都要被避免，如果无法避免，那么这些东西就会被置于解决方案之外，不予考虑。程序编写完成，会被部署到情况多变的生产环境中。如果在生产环境中出现错误，就会发布新的程序版本。Erlang则采取了与此不同的方法，Erlang认为，错误一定会发生，这些错误可能是开发人员，运维人员引起的，也可能是硬件相关的。要想根除掉程序或者系统中的所有错误，是不实际的，甚至是不可能的14。如果不用千方百计地阻止错误发生，而是能够在错误发生时去处理它们，那么我们就可以用这种方式应对几乎所有的程序未定义行为。
7、Erlang编程环境采取了和人体免疫系统一样的方法，在这个类比下，其他编程语言则只关心“卫生”情况，以防止细菌侵入人体。对我来讲，这两种方式都非常重要。几乎所有的编程环境都提供了卫生保证机制（程度可能不同）。基本上没有其他任何编程环境提供了免疫系统：可以在运行时处理错误，并视此为一种生存能力。 当刚刚出现问题时，系统并不会立即垮掉，因此Erlang/OTP 也可以使我们成为一名医生。我们可以在生产环境中直接进入到系统内部，在系统运行时仔细地观察内部的所有情况，甚至以交互式的方式修复系统。继续沿用前面的类比，在Erlang中，我们可以施行大量的测试来进行诊断，可以实施各种程度的外科手术（甚至是高侵入性的），而此时，病人却无需坐在我们边上，也无需中断自己的日常生活。