能否像在 erlang 中那样用 C 语言编写并发可扩展的可靠程序？
一个理论问题。 读完阿姆斯特朗的《programming erlang》一书后，我想知道以下问题： 学习Erlang需要一些时间。 更不用说掌握它了。 它在很多方面确实有根本的不同。
所以我的问题是：是否可以编写“像 erlang”或使用一些“像 erlang 的框架”，只要您注意不要创建具有副作用的函数，您就可以像在 Erlang 中一样创建可扩展的可靠应用程序吗？ 也许使用相同的消息发送，加载“迷你进程”范例。
这样做的好处是不必将您积累的所有 C/C++ 知识抛到一边。
任何对此的想法都会受到欢迎
a theoretical question. After reading Armstrongs 'programming erlang' book I was wondering the following:
It will take some time to learn Erlang. Let alone master it. It really is fundamentally different in a lot of respects.
So my question: Is it possible to write 'like erlang' or with some 'erlang like framework', which given that you take care not to create functions with sideffects, you can create scaleable reliable apps as well as in Erlang? Maybe with the same msgs sending, loads of 'mini processes' paradigm.
The advantage would be to not throw all your accumulated C/C++ knowledge over the fence.
Any thoughts about this would be welcome
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
是的，有可能，但是...
这个问题的最佳答案可能是 Robert Virding 的第一条规则给出的：
非常好的规则是为任务使用正确的工具。 Erlang 在并发性和可靠性方面表现出色。 C/C++ 的设计并未考虑到这些属性。
如果您不想放弃您的 C/C++ 知识和经验，并且您的项目允许这种划分，那么好的方法是创建混合解决方案。 在 Erlang 中编写并发、通信和错误处理代码，然后添加 C/C++ 部分，这将完成 CPU 和 IO 绑定的工作。
Yes, it is possible, but...
Probably the best answer for this question is given by Robert Virding’s First Rule:
Very good rule is use the right tool for the task. Erlang excels in concurrency and reliability. C/C++ was not designed with these properties in mind.
If you don't want to throw away your C/C++ knowledge and experience and your project allows this kind of division, good approach is to create a mixed solution. Write concurrent, communication and error handling code in Erlang, then add C/C++ parts, which will do CPU and IO bound stuff.
显然可以 - Erlang/OTP 系统主要是用 C（和 Erlang）编写的。 问题是“你为什么想要这样做？”
在“过去”人们曾经编写自己的操作系统 - 但你为什么要这样做呢？
如果您选择使用操作系统，您的未编写的软件具有某些属性 - 它可以持久保存到硬盘，可以与网络通信，可以在屏幕上绘图，可以从命令行运行，可以以批处理模式调用，等等...
Erlang/OTP 系统有 150 万行代码，已被证明可以在大型系统（英国电话系统）中提供 99.9999999% 的正常运行时间- 每年有 31 毫秒的停机时间。
使用 Erlang/OTP，您的未编写的软件具有高可靠性，它可以自行热插拔，您的未编写的应用程序可以当物理计算机死机时进行故障转移。
为什么要重写该功能？
You clearly can - the Erlang/OTP system is largely written in C (and Erlang). The question is 'why would you want to?'
In 'ye olde days' people used to write their own operating system - but why would you want to?
If you elect to use an operating system your unwritten software has certain properties - it can persist to hard disk, it can speak to a network, it can draw on screens, it can run from the command line, it can be invoked in batch mode, etc, etc...
The Erlang/OTP system is 1.5M lines of code which has been demonstrated to give 99.9999999% uptime in large systems (the UK phone system) - that's 31ms downtime a year.
With Erlang/OTP your unwritten software has high reliability, it can hot-swap itself, your unwritten application can failover when a physical computer dies.
Why would you want to rewrite that functionality?
我会将其分为 2 个问题
你能编写并发的、可扩展的 C++ 应用程序
是的。 当然可以创建实现这一目标所需的低级构造。
您想编写并发的、可扩展的 C++ 应用程序
也许吧。 但如果我想要一个高度并发的应用程序，我会选择一种旨在填补这一空白或很容易实现这一点的语言（Erlang、F#，可能还有 C#）。
C++ 并不是为构建高度并发的应用程序而设计的。 但它肯定可以通过调整来做到这一点。 一旦考虑到内存管理，成本可能会比您预期的要高。
I would break this into 2 questions
Can you write concurrent, scalable C++ applications
Yes. It's certainly possible to create the low level constructs needed in order to achieve this.
Would you want to write concurrent, scalable, C++ applications
Perhaps. But if I was going for a highly concurrent application, I would choose a language that was either designed to fill that void or easily lent itself to doing so (Erlang, F# and possibly C#).
C++ was not designed to build highly concurrent applications. But it can certainly be tweaked into doing so. The cost might be higher than you expect though once you factor in memory management.
是的，但你会做一些额外的工作。
关于副作用，请考虑 .net/plinq 团队的处理方式。 Plinq 无法强制您在没有副作用的情况下交给它东西，但它会假设您这样做并遵守其规则，因此我们可以使用更简单的 api。 即使该语言没有内置支持，它仍然会简化事情，因为您可以更轻松地中断操作。
Yes, but you will be doing some extra work.
Regarding side effects, consider how the .net/plinq team is approaching. Plinq won't be able to enforce you hand it stuff with no side effects, but it will assume you do so and play by its rules so we get to use a simpler api. Even if the language doesn't have built-in support for it, it will still simplify things as you can break the operations more easily.
我可以用一种图灵完整语言做的事情，我也可以用任何其他图灵完整语言做。
因此，我将您的问题解释为：用 C++ 编写可靠且可扩展的应用程序是否像在 Erlang 中一样容易？
这个问题的答案是非常主观的。 对我来说，用 C++ 编写它更容易，原因如下：
话虽如此。 如果您已经了解两种语言，并且问题已明确定义，那么您可以根据手头的所有信息做出最佳选择。
What I can do in one Turing complete language I can do in any other Turing complete language.
So I interpret your question to read, is it as easy to write a reliable and scalable application in C++ as it is in Erlang?
The answer to that is highly subjective. For me it is easier to write it in C++ for the following reasons:
Having said that. If you already know both languages, and you have the problem well defined, you can then make the best choice based on all the information you have at hand.
使用 C（或 C++）编写可靠且易于扩展的程序的主要“问题”是，在 C 中您可以做任何事情。 所以，第一步是编写一个简单的框架，稍微限制一下。 无论如何，大多数优秀的程序员都会这样做。
在这种情况下，限制主要是为了在您想要的任何隔离级别内轻松定义“进程”。
fork()因速度慢而闻名，而且线程也需要大量时间才能生成，因此您可能需要使用协作式多任务处理，这可能会更加高效，甚至可以使其成为抢占式（我认为 Erlang 就是这么做的）。 为了获得多核效率，设置一个线程池并让所有线程完成运行任务。另一个重要的部分是创建一个适当的不可变数据结构库，以便使用它们（而不是标准库）您的函数将（大部分）无副作用。
那么这只是为消息传递和未来设置一个好的 API 的问题......并不容易，但至少看起来不像改变语言本身。
the main 'problem' with C (or C++) for writing reliable and easy to extend programs is that in C you can do anything. so, the first step would be to write a simple framework that restricts just a bit. most good programmers do that anyway.
in this case, the restrictions would be mostly to make it easy to define a 'process' within whatever level of isolation you want.
fork()has a reputation of being slow, and threads also need significant time to spawn, so you might want to use a cooperative multitasking, which can be far more efficient, and you could even make it preemptive (i think that's what Erlang does). to get multi-core efficiency, set a pool of threads and make all of them complete to run the tasks.another important part would be to create an appropriate library of immutable data structures, so that using them (instead of the standard lib) your functions would be (mostly) side-effect-free.
then it's just a matter of setting a good API for message passing and futures... not easy, but at least it doesn't seem like changing the language itself.