关于actor模型的内容要少得多，而要正确编写类似于C ++中的OTP的内容要花多大的力气，要多得多。同样，不同的操作系统提供了截然不同的调试和系统工具，Erlang的VM和多种语言构造支持一种统一的方式来弄清所有这些进程所要完成的工作，而这将很难以统一的方式完成（或者也许根本）。（重要的是要记住，Erlang / OTP早于对“演员模型”一词的热议，因此在某些情况下，这类讨论是在比较苹果和翼手龙；好主意容易产生独立发明。）
所有这些意味着，尽管您当然可以用另一种语言编写一套“角色模型”程序集（我知道，我在Python，C和Guile中已经做了很长时间，但在遇到Erlang之前就没有意识到这一点，其中包括监视器和链接，并且在我还没听说过“角色模型”一词之前，请先了解您的代码实际上是如何产生的，以及其中发生了什么非常困难。Erlang执行的规则是，如果没有重大的内核大修，操作系统根本无法做-内核大修可能对整体没有好处。这些规则既体现为对程序员的一般限制（如果确实需要，可以总是解决），也可以是对程序员的系统保证的基本承诺（如果确实需要，可以故意打破）。
例如，它强制两个进程不能共享状态，以保护您免受副作用。这并不意味着每一个函数必须是“纯”，在这个意义上，一切都是引用透明（显然不是，虽然使尽可能多程序的引用透明实用是最二郎项目的一个明确的设计目标），而是两个流程并不是一直在创造与共享状态或竞争有关的竞争条件。（顺便说一下，（“副作用”在Erlang中更意味着什么；知道这可能有助于您解释一些讨论，这些问题是与Haskell或玩具“纯”语言相比，Erlang是否“确实具有功能”） ）
另一方面，Erlang运行时保证消息的传递。在必须纯粹通过非托管端口，管道，共享内存和通用文件进行通信的环境中，这是一个非常遗憾的事情，而OS内核是唯一一个管理该对象的工具（与Erlang相比，对这些资源的OS内核管理必须非常少）运行时提供）。这并不意味着Erlang保证RPC（无论如何，消息传递不是RPC，也不是方法调用！），它不保证您的消息已正确处理，也不保证您正在使用的进程试图发送一条消息到存在或仍然存在。如果您发送到的东西在那一刻是有效的，它只是保证交货。
在此承诺的基础上，保证监视器和链接准确无误。并且基于此，一旦您掌握了系统的运行情况（以及如何使用erl_connect ...），Erlang运行时就会使“网络集群”的整个概念消失。这使您可以跳过一组棘手的并发案例，这为成功案例的编码提供了很大的开端，而不会陷入裸露的并行编程所需的防御技术的泥潭。
因此，它不是真正的需要二郎，语言，其对运行时和OTP已经存在，在一个相当干净的方式被表达，并执行任何接近它的另一种语言是非常难。OTP只是很难遵循的行为。同样，我们也不是真的需要C ++，我们可以坚持使用原始二进制输入，即Brainfuck，并考虑使用Assembler作为我们的高级语言。我们也不需要火车或轮船，因为我们都知道如何走路和游泳。
综上所述，VM的字节码已被详细记录，并且出现了许多可替代的语言，可对其进行编译或与Erlang运行时一起使用。如果我们将问题分解为语言/语法部分（“我必须了解Moon Runes来进行并发吗？”）和平台部分（“ OTP是进行并发的最成熟的方法，它会指导我解决最棘手的问题吗？ ，最常见的陷阱是在并发的分布式环境中找到的？”，答案是（“否”，“是”）。