blocks|key|1123869|text|我从大学开始就认识Erlang，但到目前为止还没有在我自己的项目中使用过它。主要是因为我主要是在开发桌面应用程序，而Erlang不是一种制作漂亮GUI的好语言。但我很快就会实现一个服务器应用程序，并且我会尝试一下Erlang，因为这就是它的优势所在。但是我担心我需要更多的库，所以也许我会尝试使用Java。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1123870|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I know Erlang since university, but have never used it in my own projects so far. Mainly because I'm mostly developing desktop applications, and Erlang is not a good language for making nice GUIs. But I will soon implement a server application, and I will give Erlang a try, because that's what it's good for. But I'm worring that I need more librarys, so maybe I'll try with Java instead.

blocks|key|1338891|text|将其用于专有的、多层的二进制协议的消息网关。服务器的OTP模式和服务之间的关系以及二进制模式匹配使得开发过程变得非常容易。对于这样的用例，我可能会再次偏爱Erlang而不是其他语言。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1338892|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Used it for a message gateway for a proprietary, multi-layered, binary protocol. OTP patterns for servers and relationships between services as well as binary pattern matching made the development process very easy. For such a use case I'd probably favor Erlang over other languages again.

blocks|key|1338957|text|JVM不是一个工具，它是一个平台。尽管我完全赞成为这项工作选择最好的工具，但平台基本上已经确定了。除非我是独立开发的，从头开始，并且不想重用任何现有的代码/库(这三个方面已经不太可能是孤立的)，否则我可以自由地选择平台。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1338958|我确实使用了多种工具和语言，但我主要针对JVM平台。这就排除了Erlang用于我的大多数项目，尽管其中一些概念很有趣。|1338959|Silvio|1338960|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

The JVM is not a tool, it is a platform. Although I am all in favour of choosing the best tool for the job the platform is mostly already determined. Unless I am developing something standalone, from scratch and without the desire to reuse any existing code/library (three aspects that are unlikely in isolation already) I may be free to choose the platform.

I do use multiple tools and languages but I mainly targetg the JVM platform. That precludes Erlang for most if not all of my projects, as interesting as some of it concepts are.

Silvio

blocks|key|1124046|text|避免使用Erlang的最好理由是当您不能使用函数式编程方式时。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1124047|几周前，我读到了一篇反对Erlang的博客，作者对Erlang的批评之一是，他不知道如何让函数在每次使用相同的参数调用时返回不同的值。他真正没有意识到的是，Erlang是故意这样做的。这就是Erlang在没有显式锁定的情况下在多个处理器上运行良好的原因。纯函数式编程是无副作用的编程。您可以强迫Erlang按照我们的博客作者的要求工作，增加副作用，但这样做就丢掉了Erlang提供的价值。|1124048|纯函数式编程并不是唯一正确的编程方式。并不是每件事都需要在数学上严谨。如果您确定您的应用程序最好用一种误用术语“函数”的语言编写，那么最好将Erlang从您的列表中删除。|1124049|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

The best reason to avoid Erlang is when you cannot commit to the functional way of programming. 

I read an anti-Erlang blog rant a few weeks ago, and one of the author's criticisms of Erlang is that he couldn't figure out how to make a function return a different value each time he called it with the same arguments. What he really hadn't figured out is that Erlang is that way on purpose. That's how Erlang manages to run so well on multiple processors without explicit locking. Purely functional programming is side-effect-free programming. You can arm-twist Erlang into working like our ranting blogger wanted, adding side effects, but in doing so you throw away the value Erlang offers.

Pure functional programming is not the only right way to program. Not everything needs to be mathematically rigorous. If you determine your application would be best written in a language that misuses the term "function", better cross Erlang off your list.

blocks|key|1339169|text|我从Erlang回到Haskell是为了我的个人项目，因为Haskell令人惊叹的类型系统的简单优点。Erlang为您提供了大量工具，以便在出现问题时进行处理。Haskell为你提供了一些工具，让你从一开始就不会出错。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1339170|在具有强类型系统的语言中工作时，每次编译时都可以有效地证明有关代码的自由定理。|1339171|您还可以从Haskell的类型类机制中获得一堆重载的糖，但这在很大程度上是次要的--即使它确实允许我表达一些在Erlang中非常冗长或非惯用和不可用的抽象(例如，Haskell的类别-附加)。|1339172|我喜欢Erlang，我喜欢它的通道和它毫不费力的可扩展性。当这些是我需要的东西时，我会求助于它。Haskell不是万能的。我放弃了对空间消耗的更好的操作理解。我放弃了神奇的单程垃圾收集器。我放弃了OTP模式和所有轻松的可伸缩性。|1339173|但对于我来说，很难放弃安全保障，因为在Haskell中，通常说，如果类型检查，它可能是正确的。|1339174|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I returned to Haskell for my personal projects from Erlang for the simple virtue of Haskell's amazing type system. Erlang gives you a ton of tools to handle when things go wrong. Haskell gives you tools to keep you from going wrong in the first place.

When working in a language with a strong type system you are effectively proving free theorems about your code every time you compile.

You also get a bunch of overloading sugar from Haskell's typeclass machinery, but that is largely secondary to me -- even if it does allow me to express a number of abstractions that would be terribly verbose or non-idiomatic and unusable in Erlang (e.g. Haskell's category-extras).

I love Erlang, I love its channels and its effortless scalability. I turn to it when these are the things I need. Haskell isn't a panacea. I give up a better operational understanding of space consumption. I give up the magical one pass garbage collector. I give up OTP patterns and all that effortless scalability. 

But its hard for me to give up the security blanket that, as is commonly said, in Haskell, if it typechecks, it is probably correct.

blocks|key|1339314|text|虽然我喜欢Erlang运行时和OTP平台的许多设计方面，但我发现它是一种非常讨厌的编程语言。逗号和句号完全是无用的，而且经常需要重写许多行代码的最后一个字符，只为了更改一行。此外，一些在Ruby或Clojure中很简单的操作在Erlang中会变得单调乏味，例如字符串处理。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1339315|对于依赖于共享数据库的分布式系统，Mnesia系统非常强大，可能是一个很好的选择，但我用一种语言编程是为了学习和娱乐，一旦我读完了基本的银行帐户教程并开始为XMPP服务器编写插件，Erlang的烦人因素就开始超过乐趣因素。|1339316|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

While I liked many design aspects of the Erlang runtime and the OTP platform, I found it to be a pretty annoying program language to develop in. The commas and periods are totally lame, and often require re-writing the last character of many lines of code just to change one line. Also, some operations that are simple in Ruby or Clojure are tedious in Erlang, for example string handling.

For distributed systems relying on a shared database the Mnesia system is really powerful and probably a good option, but I program in a language to learn and to have fun, and Erlang's annoying factor started to outweigh the fun factor once I had gotten past the basic bank account tutorials and started writing plugins for an XMPP server.

blocks|key|1124393|text|从并发的角度来看，我喜欢Erlang。Erlang并发性做得很好。我最终没有使用erlang，主要是因为语法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1124394|我的职业不是函数式程序员。我通常使用C%2B%2B，所以我渴望能够在样式(OOP、命令式、元等)之间进行切换。感觉就像Erlang在强迫我敬拜不可改变的数据这头神圣的牛。|1124395|我喜欢它的并发方式，简单，美观，可伸缩，强大。但在我用Erlang编程的整个过程中，我一直在想，我更喜欢Java的一个子集，它不允许线程之间的数据共享，而是使用Erlang的并发模型。我认为Java最适合限制语言，即与Erlang的进程和通道兼容的特性集。|1124396|就在最近，我发现D+Programing+language为Erlang+style+concurrency提供了熟悉的c风格语法和多范式语言。我还没有尝试过与D大规模并发的任何东西，所以我不能说它是否是一个完美的翻译。|offset|length|1124397|因此，从专业角度讲，我使用C%2B%2B，但会像在Erlang中一样，尽最大努力为大规模并发应用程序建模。在某种程度上，我想给D的并发工具一个真正的测试驱动。|1124398|entityMap|0|LINK|mutability|MUTABLE|url|http://www.digitalmars.com/d/|1|http://www.informit.com/articles/article.aspx?p=1609144^0|0|0|0|8|L|0|U|O|1|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@$H|Z|I|10|1|11]|$H|12|I|13|1|14]]|A|$]]|$1|J|3|K|5|6|7|15|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|S]]|T|$5|O|P|Q|A|$R|U]]]]

I love Erlang from the concurrency standpoint. Erlang really did concurrency right. I didn't end up using erlang primarily because of syntax.

I'm not a functional programmer by trade. I generally use C++, so I'm covet my ability to switch between styles (OOP, imperative, meta, etc). It felt like Erlang was forcing me to worship the sacred cow of immutable-data.

I love it's approach to concurrency, simple, beautiful, scalable, powerful. But the whole time I was programming in Erlang I kept thinking, man I'd much prefer a subset of Java that disallowed data sharing between thread and used Erlangs concurrency model. I though Java would have the best bet of restricting the language the feature set compatible with Erlang's processes and channels.

Just recently I found that the <a href="http://www.digitalmars.com/d/" rel="nofollow">D Programing language</a> offers <a href="http://www.informit.com/articles/article.aspx?p=1609144" rel="nofollow">Erlang style concurrency</a> with familiar c style syntax and multi-paradigm language. I haven't tried anything massively concurrent with D yet, so I can't say if it's a perfect translation.

So professionally I use C++ but do my best to model massively concurrent applications as I would in Erlang. At some point I'd like to give D's concurrency tools a real test drive.

blocks|key|1124465|text|我想在一个项目中使用Erlang，因为它在大量CPU的情况下具有惊人的可扩展性。(我们使用其他语言，偶尔会遇到困难，这使得我们不得不调整应用程序)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1124466|问题是我们必须在几个平台上交付我们的应用程序:+Linux、Solaris和AIX，不幸的是，目前还没有针对AIX的Erlang安装。|1124467|由于操作较小，因此不需要移植和维护Erlang的AIX版本，而且要求我们的客户在应用程序的一部分使用Linux也是行不通的。|1124468|我仍然希望AIX+Erlang会出现，这样我们就可以使用它了。|1124469|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I wanted to use Erlang for a project, because of it's amazing scalability with number of CPU'S. (We use other languages and occasionally hit the wall, leaving us with having to tweak the app) 

The problem was that we must deliver our application on several platforms: Linux, Solaris and AIX, and unfortunately there is no Erlang install for AIX at the moment. 

Being a small operation precludes the effort in porting and maintaining an AIX version of Erlang, and asking our customers to use Linux for part of our application is a no go.

I am still hoping that an AIX Erlang will arrive so we can use it.

Have you actually "tried" (means programmed in, not just read an article on it) Erlang and decided against it for a project? If so, why? Also, if you have opted to go back to your old language, or to use another functional language like F#, Haskell, Clojure, Scala, or something else then this counts too, and state why.

Why did you decide "against" using Erlang?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

你是否真的“尝试过”(意思是编程，而不仅仅是读了一篇关于它的文章) Erlang，并决定在项目中不使用它？如果有，原因何在？此外，如果您选择返回到您的旧语言，或使用另一种函数式语言，如F#，Haskell，Clojure，Scala，或其他，那么这也算数，并说明为什么。

问为什么你决定“不”使用Erlang？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么你决定“不”使用Erlang？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么你决定“不”使用Erlang？
EN