您是否真的尝试过Erlang（编程的方式，而不仅仅是阅读其中的文章），并决定反对该项目？如果是这样，为什么？另外，如果您选择返回原来的语言，或者使用其他功能语言，例如F＃，Haskell，Clojure，Scala或其他某种语言，那么这也很重要，并说明原因。
Answers:
我出于Haskell惊人的类型系统的简单优点，从Erlang回到Haskell进行个人项目。当出现问题时，Erlang为您提供了大量的工具来处理。Haskell首先为您提供了防止出错的工具。
当使用具有强大类型系统的语言工作时，每次编译时，您都会有效地证明有关代码的免费定理。
您还可以从Haskell的类型类机器中获得一堆重载糖，但这对我来说是次要的-即使它确实允许我表达许多在Erlang中非常冗长或非惯用且不可使用的抽象（例如，Haskell的类别附加）。
我喜欢Erlang，也喜欢它的渠道和轻松的可扩展性。当我需要这些东西时，我会转向它。Haskell不是万能药。我放弃了对空间消耗的更好的操作理解。我放弃了神奇的一站式垃圾收集器。我放弃了OTP模式和所有那些毫不费力的可扩展性。
但是，我很难放弃通常所说的在Haskell中进行的安全保护，如果它进行类型检查，那可能是正确的。
data在其中编写定义。您需要将其写入文件，并进行REPL处理。ghci和拥抱。
我们使用Haskell，OCaml和（现在）F＃，所以对我们而言，它与缺乏C语言语法无关。相反，我们跳过Erlang是因为：
我可能现在还无法想到其他原因，但这是要点。
避免使用Erlang的最好理由是，当您无法使用编程的功能方式时。
几周前，我读了一篇反Erlang博客文章，作者对Erlang的批评之一是，他无法弄清楚如何使函数每次以相同的参数调用时都返回不同的值。他真正没有想到的是，Erlang是故意这样做的。这就是Erlang在没有显式锁定的情况下设法在多个处理器上运行良好的方式。纯函数式编程是无副作用的编程。您可以将Erlang扭曲成我们的博客作者想要的那样工作，增加副作用，但是这样做会浪费掉Erlang提供的价值。
纯粹的函数式编程不是唯一正确的编程方法。并非所有数学上都需要严格。如果您确定最好用误用“功能”一词的语言编写应用程序，则最好将Erlang排除在列表之外。
rand()在功能设计方面进行了有趣的研究。其中许多标准C库函数都是不可重入的rand()。许多C库实现都有很好的理由提供可重入的替代方案。（例如，我正在使用的计算机上的C库现在提供了纯函数可重入rand_r()。）Erlang确实提供了类似C的random:uniform()函数，但也提供了纯函数random:uniform_s()。应该使用一种版本，使两种语言都可以明确显示内部状态。
我已经在一些项目中使用过Erlang。我经常将其用于宁静的服务。但是，我不使用它的地方是复杂的前端Web应用程序，其中像Ruby on Rails这样的工具要好得多。但是对于幕后的超级经纪人，我所知没有比Erlang更好的工具。
我还使用了一些用Erlang编写的应用程序。我稍微使用了CouchDB和RabbitMQ，并设置了一些EJabberd服务器。这些应用程序是其领域中最强大，最简单和灵活的工具。
在我看来，不使用Erlang是因为它不使用JVM，这很愚蠢。JVM并不是一种神奇的工具，它可以胜任世界上所有事情。在我看来，能够从众多工具中进行选择而不会陷入单一语言或框架的能力，使专家与代码猴子区分开来。
PS：在上下文中阅读完我的评论后，我发现它看起来像是在将oxbow_lakes称为代码猴子。我真的不是，如果他那样做，我就表示歉意。我只是在概括程序员的类型，我永远不会根据他的评论将这样的人称为否定名字。即使我鼓励他不要让JVM成为某种破坏交易的人，他可能还是一个不错的程序员。
虽然我没有，但互联网上的其他人例如
我们研究了C ++和Erlang在为美国海军实施并行声射线跟踪算法时的相对优势。与基于pthread的C ++编程相比，我们发现并行Erlang的学习曲线小得多，调试环境更好。我们的C ++实现比Erlang程序至少好12倍。尝试在IBM Cell BE微处理器上使用Erlang受到Erlang的内存占用的困扰。 （资源）
还有更贴近我的内心，我记得在ICFP竞赛后回读的内容：
编码非常简单，将伪代码转换为C ++。我本可以使用Java或C＃，但目前我正处于使用C ++进行高级编程同样容易的时刻，并且我想保留以下选项：如果有的话，可以快速跳入一些低级的纠结中下去。Erlang是我最喜欢使用的另一种入侵语言，但是担心遇到一些我无法自拔的性能问题。（资源）
对我来说，Erlang是动态键入的，这让我感到警惕。虽然我做使用动态类型语言，因为他们中的一些只是这样很面向问题（以Python中，我解决了很多与它的问题），我想他们是静态类型来代替。
就是说，我实际上打算尝试Erlang一段时间，而我才刚刚开始下载源代码。因此，您的“问题”毕竟取得了一些成就。;-)
我从大学开始就认识Erlang，但是到目前为止，我从未在自己的项目中使用过它。主要是因为我主要在开发桌面应用程序，而Erlang并不是制作出色的GUI的好语言。但是我很快将实现一个服务器应用程序，并且我将尝试一下Erlang，因为这就是它的优点。但是我担心我需要更多的库，所以也许我会尝试使用Java。
原因如下：
因为它看起来与习惯于C语言族的人都不一样
因为我希望能够在Java虚拟机上运行，以利用我所了解和理解的工具（例如JConsole）以及JIT和GC多年来的努力。
因为我不想重写多年来建立的所有（Java）库。
因为我不了解Erlang的“生态系统”（数据库访问，配置，构建等）。
基本上，我熟悉Java，Java的平台和生态系统，并投入了大量精力来构建可在JVM上运行的内容。这是容易得多移动到斯卡拉
JVM不是工具，而是平台。尽管我都赞成选择最佳的工具来完成工作，但平台已经基本确定。除非我是从头开始独立开发某项东西，并且不想重用任何现有代码/库（三个方面已经不可能孤立地存在），否则我可以自由选择平台。
我确实使用多种工具和语言，但主要针对JVM平台。对于大多数（即使不是全部）项目，Erlang和某些概念一样有趣。
西尔维奥
从并发的角度来看，我爱Erlang。Erlang确实做到了并发性。我主要由于语法而没有使用erlang。
我不是专业的函数式程序员。我通常使用C ++，因此我渴望在样式之间进行切换（OOP，命令式，元数据等）。感觉就像是Erlang强迫我去敬拜不可变数据的神圣牛一样。
我喜欢它的并发方法，简单，美观，可伸缩，功能强大。但是在我一直在用Erlang编程的整个过程中，我一直在思考，老兄，我更喜欢Java的子集，该子集不允许线程之间的数据共享和使用的Erlangs并发模型。尽管Java最好限制语言与功能集兼容Erlang的进程和通道的语言。
就在最近，我发现D编程语言通过熟悉的c样式语法和多范式语言提供了Erlang样式并发。我还没有尝试任何与D并发的东西，所以我不能说它是否是完美的翻译。
因此，在专业上，我使用C ++，但我会尽最大努力为大型并发应用程序建模，就像在Erlang中一样。在某些时候，我想给D的并发工具一个真正的试驾。
我什至不去看Erlang。
有两个博客文章为我提供了帮助：
Erlang机器会遍历整个列表以确定是否有消息要处理，而获取消息的唯一方法就是遍历整个列表（我怀疑通过pid过滤消息还涉及遍历整个消息列表）
http://www.lshift.net/blog/2010/02/28/memory-matters-even-in-erlang
确实没有奇迹，Erlang不会提供太多服务来处理不可避免的过载-例如，仍然留给应用程序程序员来处理消息队列中的可用空间检查（可能是通过遍历队列来找出当前消息）。长度，我想没有内置机制可以确保发件人之间的公平性。
（1）和（2）都比我的书幼稚得多，而且我确信在Erlang机器中还有更多类似性质的软件“宝石”。
所以，对我来说没有Erlang。
看起来，一旦您不得不处理在过载下需要高性能的大型系统，C ++ + Boost仍然是唯一的游戏。
接下来我要看D。
ghci），甚至不需要写-编译-执行周期。对我而言，这将静态（〜打字）和动态语言领域的精华融为一体。