你是否真正"尝试过"（指编程而非仅仅阅读文章）Erlang，并且因为某个项目而放弃了它？如果是的话，为什么？另外，如果你选择回到旧语言或使用其他函数式语言如F＃、Haskell、Clojure、Scala或其他语言，则也计入其中，请说明原因。
15个回答
49
我从Erlang转回Haskell，用于我的个人项目，因为Haskell拥有惊人的类型系统。Erlang提供了大量工具来处理出现问题的情况。而Haskell则提供了让你在一开始就避免错误的工具。
当使用一个强类型系统的语言时，每次编译实际上都能证明你的代码是自由定理。
Haskell的类型类机制也提供了很多重载糖，但对我来说，这主要是次要的--即使它使我能够表达许多在Erlang中会非常冗长、非成语化和不可用的抽象（例如Haskell的category-extras）。
我喜欢Erlang，我喜欢它的通道和它的轻松可扩展性。当我需要这些东西时，我就会转向它。Haskell并不是万能药。我放弃了更好的操作空间消耗理解。我放弃了神奇的一遍式垃圾收集器。我放弃了OTP模式和所有轻松的可扩展性。
但我很难放弃的是那种安全保护措施，正如通常所说的，在Haskell中，如果类型检查通过，那么它很可能是正确的。
- Edward Kmett
11
26
我们使用 Haskell、OCaml 和（现在）F#，所以对我们来说与 C 语言的语法不相关。相反，我们跳过 Erlang 的原因是：
- 它是动态类型的（我们是 Haskell 类型系统的粉丝）
- 没有提供“真正”的字符串类型（我知道为什么，但这还没有在语言层面上得到纠正，这很让人恼火）
- 倾向于拥有较差的（不完整或未维护的）数据库驱动程序
- 它没有附带电池，也似乎没有社区致力于纠正这一点。如果有的话，它并不太显眼。至少 Haskell 有 Hackage，我猜这就是我们选择该语言而非其他语言的原因。在 Windows 环境中，F# 将具有终极优势。
可能还有其他原因我现在想不起来了，但这些是主要原因。
- Shaun
1
1哦，是的，有很多。但从未用于生产应用程序。评估新技术时，首先用其构建一些内部工具会有所帮助。我们喜欢Erlang，并且没有问题运行使用它的产品，如RabbitMQ，但出于已经概述的原因，我们更喜欢上面列出的技术。 - Shaun
25
避免使用Erlang的最好理由是，当您无法承诺采用函数式编程方式时。作者在几周前读了一篇反Erlang的博客，其中作者对Erlang的批评之一是他无法弄清楚如何使一个函数每次使用相同参数调用时返回不同的值。他真正没有意识到的是，Erlang是有意这样设计的。这就是Erlang在多个处理器上运行得如此流畅而无需显式锁定的原因。纯函数式编程是无副作用的编程方式。你可以让Erlang像那个发牢骚的博主希望的那样工作，并添加副作用，但这样做会丢失Erlang所提供的价值。
纯函数式编程并不是唯一正确的编程方式。并非所有应用都需要数学上的严谨性。如果您确定您的应用程序最好用误用“函数”这个术语的语言编写，最好将Erlang从您的列表中划掉。
纯函数式编程并不是唯一正确的编程方式。并非所有应用都需要数学上的严谨性。如果您确定您的应用程序最好用误用“函数”这个术语的语言编写，最好将Erlang从您的列表中划掉。
- Warren Young
2
2
rand() 是函数设计中一个有趣的研究对象。许多标准 C 库函数都是不可重入的，其中包括 rand()。许多 C 库实现提供了可重入的替代方案，这是有充分理由的。（例如，我正在使用的机器上的 C 库提供了纯函数式的可重入 rand_r()。）Erlang 提供了类似 C 的 random:uniform()，但也提供了纯函数式的 random:uniform_s()。在两种语言中都应该使用使内部状态显式的版本。 - Warren Young1一个函数为指定类型的每个输入分配精确地一个值。 - L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
16
我已经在几个项目中使用了Erlang。 我经常将其用于restful服务。 然而，对于像Ruby on Rails这样的工具更适合的复杂前端Web应用程序，我并不使用它。 但是，对于幕后的powerbroker，我知道没有比Erlang更好的工具。
我也使用了一些用Erlang编写的应用程序。 我有点使用CouchDB和RabbitMQ，并设置了一些EJabberd服务器。 这些应用程序是其领域内最强大、最易用和最灵活的工具。
因为它不使用JVM而不想使用Erlang，在我看来相当愚蠢。 JVM不是一个神奇的工具，在世界上做任何事情都是最好的。 在我看来，能够从不同工具库中选择，并且不被困在单一语言或框架中，是区分专家和代码猴子的关键。
PS：在重新阅读我的评论时，我注意到它看起来像我正在称呼oxbow_lakes为代码猴子。 我真的没有，如果他这样认为，我很抱歉。 我是在概括程序员类型，我永远不会根据他的一个评论就以如此负面的方式称呼某个人。 他可能是一位很好的程序员，尽管我鼓励他不要把JVM当作某种无法妥协的关键点。
- Jon Gretar
1
3我认为整个“它看起来不像C，所以是错误的”比JVM那部分更糟糕。如果你问我，这一切都有点儿傻。但没有人问我，所以我应该安静地呆在我的角落里。 ;) - Rayne
9
虽然我没有，但互联网上的其他人有，例如：
我们调查了在美国海军中实现并行声学射线追踪算法的C++和Erlang的相对优点。我们发现，与基于pthread的C ++编程相比，使用并行Erlang的学习曲线要小得多，并且具有更好的调试环境。我们的C ++实现至少比Erlang程序快12倍。在IBM Cell BE微处理器上使用Erlang的尝试受到Erlang的内存占用的限制。(来源)
还有一些更贴近我的内心的东西，我记得在ICFP竞赛之后阅读过：
编码非常简单，将伪代码转换为C ++即可。我可以使用Java或C＃，但是我已经达到了在C ++高级别上编程同样容易的地步，并且我希望保留快速降级到一些低级位操作的选项，如果必要的话。 Erlang是我另一个喜欢的语言，但是担心遇到一些性能问题，我无法从中解脱出来。(来源)
- Will
3
哇，我甚至不知道 Erlang 可以在 IBM Cell BE 处理器上运行。那么，Erlang 是最适合大内存环境的吗？ - yazzapps.com
8Erlang是高可靠性和高事务环境的绝佳选择。你打的电话很可能都经过基于Erlang的交换机。它在互联网服务器中也越来越常见，比如MQ和Jabber。 - Will
1电话交换机是语言的良好孕育场。AT＆T Bell甚至孵化了两种主流语言，C和C ++。在90年代的很长一段时间里，他们的电话交换机具有最高的FCC测量可靠性。但是要达到那个水平的学习曲线相当陡峭。 - MSalters
7
对我而言，Erlang 是一种动态类型语言，这让我有些警惕。虽然我确实使用过一些动态类型语言，因为其中一些非常针对问题（像 Python，我用它解决了很多问题），但我仍然希望它们是静态类型的。
话虽如此，实际上我打算尝试一下 Erlang 已经开始下载源代码。所以你的“问题”毕竟达到了某种效果。;-)
- Konrad Rudolph
6
有几个原因：
对于习惯了C语言家族的人来说，它看起来很陌生
因为我希望能够在Java虚拟机上运行，以利用我熟悉和理解的工具（如JConsole）以及多年来已经投入到JIT和GC中的努力。
因为我不想重写我多年来构建的所有（Java）库。
因为我对Erlang的“生态系统”（数据库访问、配置、构建等）一无所知。
基本上，我熟悉Java及其平台和生态系统，并且已经投入了大量精力来构建在JVM上运行的东西。相比之下，转移到Scala更加容易。
- oxbow_lakes
14
23很多编程语言看起来不像C语言，但这到底是一个优点还是缺点呢？我当然了解语法偏好，但我不确定这是否足以完全忽略一门语言。 - Rayne
7这些都是好理由，但你实际上是否编写过Erlang代码？这个问题是针对那些真正尝试过它的人提出的。 - Daniel C. Sobral
3有一些好的观点，但整个回答对我来说读起来是“我决定不这样做，因为我真的很喜欢Java”。 - ZJR
2@Rayne 冷静点。Chris 没有攻击你。相反，他只是说，因为你年龄较小，做同样的事情的时间不长，更能适应变化。如果有什么的话，他是把你的年龄当作一种优势。他不再拥有这种优势，所以他对事物的看法也不同了。例如考虑驾驶。一个在美国开车30年的人要适应在英国开车就更困难，而一个刚开始开车的人则会更容易适应。 - Daniel C. Sobral
4@ZJR - 这个答案并不是说我真的很喜欢Java（相反，我现在几乎所有东西都用scala写），而是我真正理解JVM！Java和JVM并不是同一件事情！ - oxbow_lakes
显示剩余9条评论
6
我在大学时了解了Erlang，但迄今为止从未在自己的项目中使用过它。主要是因为我主要开发桌面应用程序，而Erlang不适合制作漂亮的GUI界面。但我将很快实现一个服务器应用程序，并尝试使用Erlang，因为这正是它擅长的领域。但我担心我需要更多的库，所以也许我会尝试使用Java。
- Jonas
2
2乔·阿姆斯特朗是否专门为X窗口协议编写了Erlang适配器？我曾认为在Erlang中编写GUI会非常容易。 - Konrad Rudolph
4是的，你可以使用Erlang编写图形用户界面(GUI)。但是，如果你想要更高级的功能，比如WPF，就会变得棘手。 - Jonas
6
我决定不使用Erlang来运行我的项目，因为这个项目需要在一个多处理器系统上共享大量数据，而Clojure真正擅长于共享内存并发。当我在分布式数据存储系统上工作时，Erlang是一个很好的选择，因为Erlang在分布式消息传递系统方面表现出色。 我将项目与语言中最好的特性进行比较，并选择相应的语言。
- Arthur Ulfeldt
5
我曾将其用作专有的、多层二进制协议的消息网关。由于 OTP 模式适用于服务器和服务之间的关系，以及二进制模式匹配，使得开发过程非常容易。对于这种用例，我可能会再次偏爱 Erlang 而不是其他语言。
- yawn
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
ghci）。对我来说，这将静态（~全类型）和动态语言的优点结合在了一起。 - Konrad Rudolph