还有一点需要牢记：虽然 Erlang 在某些方面做得很好，但从技术上讲，仍然可以从其他语言中获得相同的结果。反之亦然；根据需要评估每个问题，并根据要解决的问题选择正确的工具。 Erlang 不是灵丹妙药，尤其擅长图像和信号处理、操作系统设备驱动程序等，但在服务器使用的大型软件（即：队列、地图- reduce)，结合其他语言做一些提升，更高级别的协议实现
我正在学习 Erlang，这个链接 (http://learnyousomeerlang.com/introduction#kool-aid) 让我很好奇 Erlang 应用程序的好坏之间的推理。谁能解释一下这个说法？
为什么 Erlang 在上述某些领域表现出色，而在其他领域却不擅长？
【问题讨论】：
标签： image-processing mapreduce server erlang signal-processing
当你想创建时，Erlang 是一个很好的解决方案：
实时系统：他们需要可预测的响应时间和 Erlang 抢占式调度 和 每个进程的垃圾收集 特性。
分布式系统：Erlang 具有开箱即用的分发机制和称为 Erlang 分布式协议的标准协议。
容错系统： Erlang 的轻量级进程，允许一个进程崩溃而不使其他进程崩溃，它的进程相互监督和监视机制适用于容错系统。
并发系统：虽然用 C 和 Java 等语言编写并发系统是可能的，但它可能很困难且容易出错。但是 Erlang 具有内部原语，可以轻松编写并发程序。
当您需要编写一个必须执行数字运算、图像处理之类的程序时，Erlang 不是一个好的选择，因为您的 Erlang 代码运行在某些层之上的抽象。然而，Erlang 中有官方机制可以利用C performance。另外Hipe（高性能Erlang）项目也值得考虑。
【讨论】：
Erlang 和 C 都是图灵完备的（除了缺少无限内存），因此如果您不关心绝对性能或内存量或使用的其他系统资源，两者都可以用来计算任何东西。
在内存受限的系统（tinyDuino 等）中，语言运行时占用空间（以及支持该运行时所需的操作系统资源）可能是一个差异化因素。对于每秒每个乘法累加都很重要的问题（影响以兆瓦天为单位的总成本或延迟的微秒），任何可能隐含在正式语言定义中的额外类型或值检查、复制或转换可能会导致处理器周期、高速缓存未命中或运行时内存管理方面的额外性能成本。对于某些类型的应用程序，可以指定一个 C 程序而没有上述太多开销。但是，在需要此类开销以实现稳健解决方案的应用程序中，与编写等效（或更多）稳健解决方案的预期人力成本相比，这种性能优势消失了。
【讨论】：
虽然 Erlang 在某些方面做得很好，但从技术上讲，仍然可以从其他语言中获得相同的结果
让我们面对现实吧，实际上所有编程语言或多或少都可以做任何事情，并且有办法与 C 库接口以访问它们没有原生库的任何东西。
要指出的最明显的一点是，归根结底，所有 Erlang 都归结为 C，还有一点汇编程序，但这与重点无关。
因此，您应该很清楚，您可以用 Erlang 编写的任何东西都可以用 C 编写，并且因为您正在消除抽象和解释层，如果您做得合理，它应该会更快。有时会快一点。有时会快很多。
Erlang 不是灵丹妙药，在图像和信号处理、操作系统设备驱动程序等方面尤其糟糕。
这是一个真正的字节和位移魔术的舞台，如果您为每个位移位引入一个抽象层......您很容易最终将可能实现的最佳性能降低多个数量级。
并且会在诸如服务器使用的大型软件（即：队列、map-reduce）、与其他语言结合进行一些提升、更高级别的协议实现等方面大放异彩
这是有趣的一点。我们已经确定，如果你用 C 编写它，除非你的工作做得很差，否则结果只会在性能方面更好。
但性能并不是一切。在当今世界，CPU 和内存很便宜，但上市时间非常重要。一家公司可能会花费数千美元购买运行您的应用程序所需的额外硬件，因为它是用 Erlang 而不是 C 编写的，但由于该产品是第一个推向市场的，因此可以节省（或赚取）数百万美元。
事实是，如果您将给定的软件问题与具有正确范式的高级语言相匹配，则普通软件工程师通常可以比使用 C 语言编写给定产品快很多倍。
此外，编写 C 语言很容易出错，并且为犯错和错误选择提供了更大的空间。这意味着软件工程师可能会用 C 编写一些东西，以至于等效的 Erlang，基于一些非常精细调整的成熟聪明的 C，如果 Erlang 本身做得很好，它可能会表现得更好！
根据需要评估每个问题，并根据要解决的问题选择合适的工具
一般来说，Erlang 是一个非常棒的工具，但它确实比其他领域更适合某些问题领域。有些问题可能会更好地用 perl 或 C、python 等来解决。当它适合问题域时，Erlang 可能是无与伦比的，但如果它不适合，绝对最好考虑其他东西。
【讨论】：