一个理论问题。在阅读了 Armstrongs 的“programming erlang”一书后，我想知道以下几点：学习 Erlang 需要一些时间。更别说掌握它了。它在很多方面确实有根本的不同。
所以我的问题是：是否可以编写'like erlang'或使用一些'erlang like framework'，考虑到你注意不要创建带有副作用的函数，你可以像在Erlang中一样创建可扩展的可靠应用程序？也许使用相同的消息发送，大量的“迷你流程”范式。
这样做的好处是不会将您积累的所有 C/C++ 知识抛在一边。
欢迎对此提出任何想法
是的，这是可能的，但是......
罗伯特·维丁的第一条规则可能给出了这个问题的最佳答案：
“任何用另一种语言编写的足够复杂的并发程序都包含一个临时的、非正式指定的、漏洞百出的、缓慢的一半 Erlang 实现。”</p>
非常好的规则是使用正确的工具来完成任务。Erlang 在并发性和可靠性方面表现出色。C/C++ 在设计时并未考虑到这些属性。
如果您不想丢掉您的 C/C++ 知识和经验，并且您的项目允许这种划分，那么好的方法是创建一个混合解决方案。在 Erlang 中编写并发、通信和错误处理代码，然后添加 C/C++ 部分，这将执行 CPU 和 IO 绑定的东西。
您显然可以 - Erlang/OTP 系统主要是用 C（和 Erlang）编写的。问题是“你为什么要这样做？”
在'ye olde days'人们过去常常编写自己的操作系统 - 但你为什么要这样做？
如果您选择使用操作系统，您的未编写软件具有某些属性 - 它可以持久保存到硬盘、可以与网络通信、可以在屏幕上绘图、可以从命令行运行、可以在批处理模式下调用等等等等……
Erlang/OTP 系统是 150 万行代码，已被证明在大型系统（英国电话系统）中提供 99.9999999% 的正常运行时间 - 即每年 31 毫秒的停机时间。
使用 Erlang/OTP，您的未编写软件具有高可靠性，它可以自行热插拔，您的未编写应用程序可以在物理计算机死机时进行故障转移。
为什么要重写该功能？
我会把它分成2个问题
你能编写并发的、可扩展的 C++ 应用程序吗？
是的。为了实现这一点，当然可以创建所需的低级构造。
您想编写并发、可扩展的 C++ 应用程序吗？
也许。但是，如果我要开发一个高度并发的应用程序，我会选择一种语言，要么旨在填补这一空白，要么很容易做到这一点（Erlang、F# 和可能的 C#）。
C++ 不是为构建高度并发的应用程序而设计的。但它当然可以调整为这样做。但是，一旦考虑到内存管理，成本可能会比您预期的要高。
是的，但你会做一些额外的工作。
关于副作用，请考虑 .net/plinq 团队的处理方式。Plinq 将无法强制您提交没有副作用的东西，但它会假设您这样做并遵守其规则，因此我们可以使用更简单的 api。即使该语言没有对它的内置支持，它仍然会简化事情，因为您可以更轻松地破坏操作。
我可以用一种图灵完备语言做的事情 我可以用任何其他图灵完备语言做。
因此，我将您的问题解读为：用 C++ 编写可靠且可扩展的应用程序是否像在 Erlang 中一样容易？
答案是非常主观的。对我来说，用 C++ 编写它更容易，原因如下：
话说回来。如果您已经了解这两种语言，并且已经明确定义了问题，那么您可以根据手头的所有信息做出最佳选择。
使用 C（或 C++）编写可靠且易于扩展的程序的主要“问题”是在 C 中您可以做任何事情。所以，第一步是编写一个简单的框架，只限制一点。无论如何，大多数优秀的程序员都会这样做。
在这种情况下，这些限制主要是为了在您想要的任何隔离级别内轻松定义“进程”。 fork()以缓慢着称，而且线程也需要大量时间来生成，因此您可能希望使用协作式多任务处理，这可能会更有效率，您甚至可以使其成为抢先式（我认为这就是 Erlang 所做的）。要获得多核效率，请设置一个线程池并让它们全部完成以运行任务。
另一个重要部分是创建一个适当的不可变数据结构库，以便使用它们（而不是标准库）您的函数将（大部分）无副作用。
那么这只是为消息传递和期货设置一个好的 API 的问题......并不容易，但至少它看起来不像改变语言本身。