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

JVM不是一个工具，而是一个平台。虽然我赞成选择最适合工作的工具，但大多数情况下平台已经确定了。除非我正在开发一些独立的、从头开始的东西，并且没有重用任何现有的代码/库（这三个方面本身就不太可能同时存在），否则我可以自由选择平台。
我确实使用多种工具和语言，但主要针对JVM平台。这使得Erlang在我的大多数项目中都不适用，尽管它的某些概念很有趣。
Silvio

虽然我喜欢Erlang运行时和OTP平台的许多设计方面，但我发现它是一种相当烦人的编程语言。逗号和句号非常糟糕，并且通常需要重新编写许多代码行的最后一个字符才能更改一个行。此外，一些在Ruby或Clojure中简单的操作在Erlang中很繁琐，例如字符串处理。
对于依赖共享数据库的分布式系统，Mnesia系统确实非常强大，可能是一个不错的选择。但我编程是为了学习和娱乐，而Erlang的烦人因素开始超过了有趣因素，一旦我完成了基本的银行账户教程并开始为XMPP服务器编写插件。

从并发性的角度来看，我喜欢Erlang。 Erlang确实做到了并发。但是，因为语法问题，我最终没有使用Erlang。

我的职业并不是函数式编程员。我通常使用C++，所以我很珍惜我能够在面向对象编程、命令式编程和元编程等各种风格之间切换的能力。感觉Erlang迫使我崇尚不可变数据的神圣牛。

我很喜欢Erlang对并发的处理方式——简单、美观、可扩展、强大。但是，在编写Erlang程序的整个过程中，我一直在想，我更喜欢一个子集Java，该子集禁止线程之间共享数据，并使用Erlang的并发模型。我认为Java是限制语言特性且与Erlang的进程和通道兼容的最佳选择。

最近，我发现D编程语言提供了类似Erlang的并发性，具有熟悉的c样式语法和多范式语言。我还没有用D尝试过大规模并发，所以我无法判断它是否是完美的替代。

因此，就我的职业而言，我使用C++，但尽最大努力像在Erlang中一样对大规模并发应用程序进行建模。在某个时候，我想真正地测试一下D的并发工具。

我甚至不会考虑使用Erlang。

有两篇博客文章让我认为：

1. Erlang机制需要遍历整个列表以确定是否有消息要处理，而获取消息的唯一方法是遍历整个列表（我怀疑通过pid过滤消息也涉及遍历整个消息列表）

   http://www.lshift.net/blog/2010/02/28/memory-matters-even-in-erlang

2. 没有奇迹，实际上，Erlang并没有提供太多服务来处理不可避免的超载 - 例如，仍然留给应用程序员检查消息队列中是否有可用空间（可能通过遍历队列来确定当前长度，并且我想没有内置机制来确保发送方之间的某种公平性）。

   erlang - how to limit message queue or emulate it?

这两点都在我的书中被认为是非常幼稚的，我相信还有更多类似的软件“宝石”隐藏在Erlang机制中。

所以，对于我来说，不使用Erlang。

似乎一旦你必须处理需要高性能的大型系统，C++ + Boost仍然是唯一的选择。

我接下来会看看D语言。

我想使用Erlang开展一个项目，因为它在应对多个CPU方面的可扩展性非常强。（我们使用其它语言时偶尔会遇到瓶颈，不得不对应用进行调整）

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

我们是一个小型团队，难以投入精力来移植和维护AIX版本的Erlang，并且要求我们的客户在应用程序的某个部分使用Linux是行不通的。

我仍然希望有一款适用于AIX的Erlang版本可以问世，这样我们就可以使用它了。