你为什么决定“反对”使用Erlang？
你真的“试过”（意味着编程，而不只是读一篇文章）Erlang，并决定反对它的一个项目？ 如果是这样，为什么？ 此外，如果您select回到您的旧语言，或者使用F＃，Haskell，Clojure，Scala或其他function语言，那么这也是非常重要的，并说明原因。
我回到了Haskell，从Erlang的个人项目中获得了Haskell惊人types系统的简单优点。 Erlang为您提供了大量工具来处理错误。 Haskell为您提供了一些工具，以防止您首先出错。
当使用强types系统的语言工作时，每次编译时都可以有效地certificate关于代码的自由定理。
你也可以从Haskell的types机制中得到一堆重载的糖，但是这对我来说基本上是次要的，即使它允许我expression一些在Erlang中非常冗长或非惯用和不可用的抽象（例如Haskell's类别的演员）。
我喜欢Erlang，我喜欢它的渠道和不费吹灰之力。 当这些是我需要的东西时，我会转向它。 哈斯克尔不是万能的。 我放弃了对空间消费更好的操作理解。 我放弃了一个神奇的垃圾收集器。 我放弃OTP模式和所有这些毫不费力的可扩展性。
但是，对于我们来说，放弃这个安全防护层是非常困难的，正如通常所说的那样，在Haskell中，如果它检测到了，那么可能是正确的。
我们使用Haskell，OCaml和（现在的）F＃，所以对于我们来说，它与缺乏类C语法毫无关系。 相反，我们跳过Erlang，因为：
- 它是dynamictypes的（我们是Haskell的types系统的粉丝）
- 不提供一个“真正的”stringtypes（我明白为什么，但这很烦人，这还没有在语言水平上得到纠正）
- 往往有穷人（不完整或无人维护）的数据库驱动程序
- 这不包括电池，似乎没有一个社区正在纠正这一问题。 如果是这样，它不是很明显。 Haskell至less有Hackage，我想这就是我们select哪种语言。 在Windows环境下，F＃在这里将有最终的优势。
可能还有其他原因，我现在无法想到，但这些都是重点。
避免Erlang的最好的理由是当你不能承担编程的function。
我几个星期前读了一篇反Erlang的博客文章，作者对Erlang的批评之一就是，他不知道如何在每次用相同的参数调用函数时返回一个不同的值。 他真的没有想到Erlang是故意的。 这就是Erlang如何在没有显式locking的情况下在多处理器上运行得如此之好。 纯function编程是无副作用的编程。 你可以用胳膊扭曲Erlang，像我们咆哮的博主想要的那样工作，增加副作用，但是这样做可以抛弃Erlang提供的价值。
纯function编程并不是唯一正确的编程方式。 并非所有的事情都需要math上的严谨。 如果您确定您的应用程序最好是用误用“function”一词的语言编写的，则最好将Erlang从您的列表中删除。
我已经在一些项目中使用了Erlang。 我经常用它来享受宁静的服务。 但是，如果我不使用它，那么对于复杂的前端Web应用程序，Ruby on Rails等工具要好得多。 但是对于幕后的权力经纪人，我知道没有比Erlang更好的工具。
我也使用Erlang编写的几个应用程序。 我使用了CouchDB和RabbitMQ，并且设置了一些EJabberd服务器。 这些应用程序是其领域内最强大，最简单，最灵活的工具。
不想使用Erlang，因为它不使用JVM，在我看来很愚蠢。 JVM并不是一个神奇的工具，它是世界上最好的工具。 在我看来，从不同工具库中进行select，而不是陷入单一语言或框架的能力是将专家与代码猴分开的能力。
PS：在阅读我的评论回到上下文后，我注意到它看起来像我正在呼吁oxbow_lakes一个代码猴子。 如果他这样做，我真的不是道歉。 我正在对程序员的types进行概括，而且我绝不会根据他的一个评论来称呼这样一个负面的名字。 他可能是一个优秀的程序员，尽pipe我鼓励他不要让JVM成为某种交易断路器。
虽然我没有，互联网上的其他人也有，例如
我们研究了C ++和Erlang在为美国海军实施平行声射线追踪algorithm方面的相对优点。 与基于pthreads的C ++编程相比，我们发现并行Erlang的学习曲线和debugging环境要小得多。 我们的C ++实现性能比Erlang程序至less高出12倍。 试图在IBM Cell BE微处理器上使用Erlang，Erlang的内存占用情况令人沮丧。 （资源）
还有一些更接近我的内心的东西，我记得在ICFP大赛结束之后，
编码非常简单，将伪代码翻译成C ++。 我本来可以使用Java或C＃，但是我正处在用C ++高级编程的地步，而且我希望保留快速下降到一些低级别位置的选项一直到它。 Erlang是我最喜欢的入侵语言，但是却担心遇到一些我无法解脱的性能问题。 （资源）
对于我来说，Erlang是dynamicinput的，这让我很担心。 虽然我使用dynamictypes化语言，因为其中有些是非常非常面向问题的（使用Python，我解决了很多问题），但我希望它们是静态types化的。
也就是说，我实际上打算给Erlang一段时间的尝试，我刚开始下载源代码。 所以你的“问题”毕竟取得了成果。 😉
我从大学以来就认识Erlang，但到目前为止我从未在自己的项目中使用它。 主要是因为我主要是在开发桌面应用程序，而Erlang并不是制作漂亮graphics用户界面的好语言。 但是我很快就会实现一个服务器应用程序，我会试试Erlang，因为这就是它的优点。 但是我很担心我需要更多的图书馆，所以也许我会用Java来尝试。
一些原因：
-
因为它看起来与任何习惯于C语言家族的人都是陌生的
-
因为我希望能够在Java虚拟机上运行，充分利用我熟悉和了解的工具（如JConsole）以及已经进入JIT和GC的多年努力。
-
因为我不想重写所有多年来build立起来的（Java）库。
-
因为我不知道Erlang的“生态系统”（数据库访问，configuration，构build等）。
基本上我熟悉Java，它的平台和生态系统，我已经投入了很多精力来构build在JVM上运行的东西。 转移到scala是比较容易的
我决定不使用Erlang来处理我的项目，这个项目将在一个多处理器系统上运行很多共享数据，而且随着Clojure的推出，Clojure真的获得了共享内存的并发性。 当我在分布式数据存储系统上工作时，Erlang非常适合，因为Erlang真的非常适合分布式消息传递系统。 我将该项目与该语言中的最佳function进行比较，然后相应地进行select
用于专有的，多层次的二进制协议的消息网关。 服务器的OTP模式和服务之间的关系以及二进制模式匹配使开发过程变得非常简单。 对于这样的用例，我可能会再次倾向于Erlang。
JVM不是一个工具，它是一个平台。 虽然我都赞成select最好的工具，但平台已经基本确定了。 除非我正在单独开发一些独立的，无需重复使用任何现有代码/库的东西（三个方面已经不太可能），我可以自由select平台。
我确实使用了多种工具和语言，但主要是针对JVM平台。 这就排除了Erlang的大部分，如果不是我所有的项目，就像其中一些概念一样有趣。
西尔维奥
虽然我喜欢Erlang运行时和OTP平台的许多devise方面，但是我发现它是一个非常烦人的编程语言。逗号和句点完全是蹩脚的，通常需要重写许多行的最后一个字符代码只是改变一行。 另外，在Ruby或Clojure中一些简单的操作在Erlang中是很乏味的，例如string处理。
对于依赖共享数据库的分布式系统，Mnesia系统是非常强大的，也许是一个很好的select，但是我用一门语言来编程并获得乐趣，而Erlang的烦人因素一旦超过了基础银行帐户教程，并开始编写XMPP服务器的插件。
我从并发的angular度来看Erlang。 Erlang真的做了并发权。 主要是因为语法，我并没有最终使用erlang。
我不是一个function强大的程序员。 我通常使用C ++，所以我很想要在样式（OOP，命令式，元等）之间切换。 感觉Erlang在强迫我崇拜不变数据的神牛。
我喜欢它的并发性，简单，美观，可扩展，强大的方法。 但是在Erlang编程的整个过程中，我一直在想，人们更喜欢Java的一个子集，它不允许在线程和使用的Erlangs并发模型之间共享数据。 我认为Java会限制语言的function集与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没有提供太多的服务来处理不可避免的重载 – 例如，应用程序员仍然需要处理消息队列中可用空间的检查（假设通过在队列中找出当前的长度，我想没有内置的机制，以确保发送者之间的公平性）。
erlang – 如何限制消息队列或模拟它？
我的书上（1）和（2）都是天真的，我相信Erlang机器里面还有更多类似的软件“gem”。
所以，没有Erlang对我来说。
看来，一旦你必须处理一个需要高性能的大型系统，C ++ + Boost仍然是镇上唯一的游戏。
接下来我要看看D.
我想用一个项目来使用Erlang，因为它具有令人惊叹的可扩展性和CPU的数量。 （我们使用其他语言，偶尔撞墙，让我们不得不调整应用程序）
问题是，我们必须在多个平台上交付我们的应用程序：Linux，Solaris和AIX，不幸的是，目前没有针对AIX的Erlang安装。
作为一个小型的操作，无法在移植和维护一个AIX版本的Erlang，并要求我们的客户在我们的应用程序中使用Linux是不行的。
我仍然希望AIX Erlang能够到达，所以我们可以使用它。
