为什么你决定“反对”使用 Erlang？

小开

原因有以下几点:

因为它看起来与任何习惯于 C 语言家族的人都很陌生
因为我希望能够在 Java 虚拟机上运行，以便利用我了解和理解的工具(如 JConsole)以及多年来投入到 JIT 和 GC 中的努力。
因为我不想重写多年来构建的所有(Java)库。
因为我对 Erlang“生态系统”(数据库访问、配置、构建等)一无所知。

基本上我熟悉 Java，它的平台和生态系统，我已经投入了很多精力来构建在 JVM 上运行的东西。转移到 Scala 是 更容易

小开

虽然我没有，但网上的其他人有，例如。

我们研究了... ... 的相对优点实现中的 C + + 和 Erlang 平行声线追踪美国海军的算法，我们发现学习曲线要小得多更好的调试环境平行二郎比基于 pthread 的 C + + 编程 C + + 实现的性能优于 Erlang 程序至少增加12倍。试图在 IBM Cell 上使用 Erlang 被微处理器挫败了 Erlang 的内存占用。(图片来源: http://portal.acm.org/citation.cfm? id = 1411223 & amp; dl = GUIDE & amp; coll = GUIDE & amp

还有一些更贴近我内心的东西，我记得在 ICFP 比赛后读到过:

编码很简单, 将伪代码转换成 C + + 可以使用 Java 或 C # ，但我在程序设计达到高潮的地方 C + + 的水平一样简单，而我想尽快保留降落到某个低层如果真到了那个地步，我们也只能玩玩而已。 Erlang 是我最喜欢的另一种语言但是我很担心关于表演的事我无法解决的问题译自: 美国《科学》杂志网站(http://blogs.msdn.com/cashto/archive/2007/07/23/the-icfp-10th-year-Programming-conte.aspx)

小开

我从大学起就认识 Erlang，但是到目前为止还没有在我自己的项目中使用过它。主要是因为我主要是在开发桌面应用程序，而 Erlang 并不是一个制作漂亮图形用户界面的好语言。但是我将很快实现一个服务器应用程序，并且我将尝试 Erlang，因为这是它的优点。但是我担心我需要更多的库，所以也许我会尝试用 Java 代替。

小开

对于我来说，Erlang 是动态类型的这一事实让我很谨慎。虽然我使用做动态类型语言，因为它们中的一些非常面向问题(以 Python 为例，我用它解决了很多问题) ，但我希望它们是静态类型的。

也就是说，我实际上打算尝试 Erlang 一段时间，我刚刚开始下载源代码。看来你的“问题”还是有所收获的。;-)

小开

它用于私有的、多层的、二进制协议的消息网关。服务器的 OTP 模式、服务之间的关系以及二进制模式匹配使得开发过程非常简单。对于这样的用例，我可能会再次选择 Erlang 而不是其他语言。

小开

我已经在一些项目中使用了 Erlang。我经常用它来做休息服务。然而，我不使用它的地方是在复杂的前端 Web 应用程序中，像 RubyonRails 这样的工具要好得多。但对于幕后的政治掮客来说，我知道没有比 Erlang 更好的工具了。

我还使用了一些在 Erlang 编写的应用程序。我稍微使用了 CouchDB 和 RabbitMQ，并且设置了一些 EJabberd 服务器。这些应用程序是其领域中最强大、最简单和最灵活的工具。

在我看来，不想使用 Erlang 因为它不使用 JVM 是相当愚蠢的。JVM 不是什么神奇的工具，它不是世界上最好的工具。在我看来，专家和代码工程师之间的区别在于，他们能够从众多不同的工具中进行选择，而不会被单一的语言或框架所束缚。

PS: 在回顾了我的评论后，我注意到我好像把 oxbow _ lake 叫做代码猴子。我真的没有，如果他那样对我，我道歉。我是在概括程序员的类型，我绝不会因为一个人的一句话就给他起这样负面的名字。他可能是一个优秀的程序员，尽管我鼓励他不要让 JVM 成为某种破坏协议的因素。

小开

JVM 不是一个工具，而是一个平台。尽管我完全赞成为这份工作选择最好的工具，但这个平台基本上已经确定下来了。除非我正在开发一些独立的东西，从头开始，并且不想重用任何现有的代码/库(三个方面已经不太可能是孤立的) ，否则我可以自由地选择平台。

我使用多种工具和语言，但主要针对 JVM 平台。对于我的大多数项目(如果不是全部的话) ，Erlang 都被排除在外，尽管它的一些概念很有趣。

西尔维奥

小开

避免使用 Erlang 的最佳原因是当您无法使用函数式编程方式时。

几周前，我读到一篇反对 Erlang 的博客，作者对 Erlang 的一个批评是，他不知道如何让一个函数每次调用相同的参数时返回一个不同的值。他真正没想到的是 Erlang 是故意这么做的。这就是 Erlang 如何在没有显式锁定的情况下在多处理器上很好地运行的原因。纯函数式编程是没有副作用的编程。您可以强迫 Erlang 按照我们的咆哮博客所希望的那样工作，增加副作用，但是这样做会抛弃 Erlang 提供的价值。

纯函数式编程并不是编程的唯一正确方法。并不是所有事情都需要严谨的数学计算。如果您确定您的应用程序最好使用一种滥用术语“ function”的语言编写，那么最好将 Erlang 从列表中划掉。

小开

最佳答案

我从 Erlang 回到哈斯克尔从事我的个人项目，因为哈斯克尔令人惊叹的打字系统的简单优点。Erlang 为您提供了大量工具，以便在出现问题时进行处理。Haskell 为您提供了从一开始就避免出错的工具。

当使用一种具有强类型系统的语言时，每次编译时都能有效地证明关于代码的自由定理。

你也可以从 Haskell 的类型类机器中得到一大堆过载的糖，但这在很大程度上对我来说是次要的——即使它确实允许我表达一些抽象概念，这些抽象概念可能非常冗长或不惯用，在 Erlang 无法使用(例如 Haskell 的类别-额外的)。

我喜欢 Erlang，我喜欢它的通道和毫不费力的可伸缩性。当我需要这些东西的时候，我就会求助于它。Haskell 不是万能药。我放弃了对空间消耗更好的操作理解。我放弃神奇的一次性垃圾收集器。我放弃了 OTP 模式和轻松的可伸缩性。

但我很难放弃“安全毯”——正如人们通常所说的那样，在哈斯克尔，如果它进行了打字检查，那么它很可能是正确的。

小开

我们使用 Haskell、 OCaml 和(现在) F # ，所以对我们来说，它与缺乏类 C 语法没有任何关系。我们跳过 Erlang 是因为:

它是动态类型化的(我们是 Haskell 类型系统的粉丝)
没有提供一个“真正的”字符串类型(我知道为什么，但是在语言级别上还没有纠正这个问题，这很烦人)
数据库驱动程序往往很差(不完整或未维护)
它没有包括电池，似乎也没有一个社区致力于纠正这个问题。就算有，也不是很明显。Haskell 至少还有 Hackage 我猜这就是我们选择这种语言的原因。在 Windows 环境下，F # 将在这里拥有终极优势。

也许还有其他我现在想不出来的原因，但是这些是主要的原因。

小开

我决定不在我的项目中使用 Erlang，因为这个项目将在单个多处理器系统上运行大量共享数据，我选择了 Clojure，因为 Clojure 实际上获得了共享-内存-并发性。当我在分布式数据存储系统上工作时，Erlang 非常适合，因为 Erlang 在分布式消息传递系统上非常出色。我将项目与语言中的最佳特性进行比较，并做出相应的选择

小开

虽然我喜欢 Erlang 运行时和 OTP 平台的许多设计方面，但是我发现它是一种非常烦人的开发程序语言。逗号和句号非常蹩脚，通常需要重写许多行代码的最后一个字符，仅仅是为了更改一行。此外，一些在 Ruby 或 Clojure 中很简单的操作在 Erlang 也很乏味，例如字符串处理。

对于依赖于共享数据库的分布式系统来说，Mnesia 系统非常强大，可能是一个不错的选择，但是我用一种语言编程是为了学习和享受乐趣，而 Erlang 的烦人因素开始超过乐趣因素，一旦我通过了基本的银行账户教程并开始为 XMPP 服务器编写插件。

小开

从并发的角度来看，我喜欢 Erlang。Erlang 确实做到了并发性。由于语法的原因，我最终没有使用 erlang。

我的职业不是函数式程序员。我通常使用 C + + ，所以我渴望在不同样式(OOP、命令式、元等)之间切换的能力。感觉就像 Erlang 在逼我崇拜不可变数据的圣牛。

我喜欢它的并发方法，简单、漂亮、可伸缩、强大。但是在我在 Erlang 编程的时候，我一直在想，伙计，我更喜欢 Java 的一个子集，它禁止线程之间的数据共享，并且使用了 Erlang 并发模型。我认为 Java 最有可能限制语言的特性集与 Erlang 的进程和通道兼容。

就在最近，我发现编程语言为 Erlang 风格并发提供了熟悉的 c 样式语法和多范式语言。我还没有尝试过任何与 D 大规模并发的东西，所以我不能说它是否是一个完美的翻译。

因此，在专业上，我使用 c + + ，但尽我最大努力为大规模并发应用程序建模，就像我在 Erlang 做的那样。在某些时候，我想给 D 的并发工具一个真正的测试驱动。

小开

我看都不会看 Erlang 一眼。

两篇博客文章为我揭晓了答案:

Erlang 机器遍历整个列表以确定它们是否有要处理的消息，获取消息的唯一方法是遍历整个列表(我怀疑通过 pid 过滤消息也涉及遍历整个消息列表)

Http://www.lshift.net/blog/2010/02/28/memory-matters-even-in-erlang
事实上，Erlang 没有提供太多的服务来处理不可避免的过载——例如，它仍然留给应用程序程序员来处理消息队列中可用空间的检查(假设通过遍历队列来计算当前的长度，我认为没有内置的机制来确保发送者之间的公平性)。

Erlang-如何限制消息队列或模拟它？

在我的书中，(1)和(2)都远远低于天真，我相信在 Erlang 机器内部还有更多类似性质的软件“宝石”。

所以，我不要二郎。

看来，一旦你必须处理一个大型系统，需要高性能下超载 C + + + 升级仍然是唯一的游戏在城市。

接下来我要看 D。

小开

我想在一个项目中使用 Erlang，因为它具有惊人的可伸缩性和 CPU 的数量。(我们使用其他语言，偶尔也会碰壁，这让我们不得不调整应用程序)

问题在于，我们必须在几个平台上交付应用程序: Linux、 Solaris 和 AIX，不幸的是，目前还没有为 AIX 安装 Erlang。

作为一个小型操作系统，我们无法移植和维护 Erlang 的 aIX 版本，要求我们的客户在我们的应用程序中使用 Linux 是不可能的。

我仍然希望 AIX Erlang 能够出现，这样我们就可以使用它了。