Why did you decide against using Erlang?

Question

In fact, you "tried" (which means you programmed, and not just read the article on it) Erlang and decided against it for the project? If so, why? In addition, if you decide to go back to your old language or use another functional language, such as F #, Haskell, Clojure, Scala or something else, then this is also considered, and indicate why.

Answer 1

I returned to Haskell for my personal projects from Erlang for the sheer virtue of a Haskell system with an amazing type. Erlang gives you tons of tools to handle when things go wrong. Haskell gives you tools to help you stay safe first.

When working in a language with a strong type system, you arbitrarily prove free theorems about your code with every compilation.

You also get a ton of sugar overload from Haskell class machines, but this is pretty much secondary to me - even if it allows me to express a few abstractions that would be terribly detailed or non-idiomatic and unsuitable for use in Erlang (e.g. additional Haskell categories).

I love Erlang, I like its channels and its easy scalability. I turn to him when this is what I need. Haskell is not a panacea. I refuse a better understanding of outer space. I throw a magical scavenger one. I am abandoning OTP patterns and all this easy scalability.

But it's hard for me to abandon the protective blanket, which, as they usually say, in Haskell, if it looks probably right.

Answer 2

We use Haskell, OCaml, and (now) F #, so for us this has nothing to do with the lack of type C syntax. Rather, we skip Erlang because:

• This is dynamically typed (we are fans of a system like Haskell)
• Doesn't provide a “real” type of string (I understand why, but it is annoying that it has not yet been fixed at the language level)
• Tends to have poor (incomplete or incomplete) database drivers
• These are not batteries, and it seems the community is not working to fix this. If so, it is not very noticeable. Haskell at least has Hackage, and I would suggest that we choose this language over any other. In Windows F # environments, it’s about to get the ultimate advantage.

There are probably other reasons that I cannot think of right now, but these are the main points.

Answer 3

The best reason to avoid Erlang is when you cannot complete a functional way of programming.

I read the anti-Erlang blog disclosure a few weeks ago, and one of the critics of Erlang was that he couldn’t figure out how to get a function to return a different value every time he called it with the same arguments, What it on didn't really understand - this is what Erlang specifically. The way Erlang manages to work so well on multiple processors without explicit blocking. Purely functional programming is free programming. You can tweak Erlang to work, as we would like our blogger to want, adding side effects, but at the same time you throw away the value that Erlang offers.

Purely functional programming is not the only correct way to program. Not everything has to be mathematically rigorous. If you determine that your application is best written in a language that abuses the term "function", it is better to cross Erlang from your list.

Answer 4

I have already used Erlang in several projects. I often use it for quiet services. Where I don't use it, for complex web applications where tools like Ruby on Rails are much better. But for a powerbroker backstage, I don't know a better tool than Erlang.

I also use several applications written in Erlang. I use CouchDB and RabbitMQ a bit, and I created several EJabberd servers. These applications are the most powerful, simple and flexible tools in their field.

I do not want to use Erlang because it does not use the JVM, in my opinion, is pretty stupid. JVM is not a magic tool that does everything in the world best. In my opinion, the ability to choose various tools from the arsenal and not get stuck in one language or structure is what separates experts from code monkeys.

PS: After reading my comment in context, I noticed that it looks like I was calling oxbow_lakes with a code monkey. I really was not and apologized if he did so. I generalized about the types of programmers, and I would never have called such a negative name based on one of his comments. He is probably a good programmer, although I urge him not to turn the JVM into a kind of deal breaker.

Answer 5

While I don’t have others on the Internet, for example,

We investigated the relative merits of C ++ and Erlang in the implementation of parallel acoustic ray tracing algorithm for the US Navy. We found a much smaller learning curve and an improved debugging environment for parallel Erlang than for programming with C ++ based on pthreads. our C ++ Implementation has surpassed Erlang at least 12 times. Attempts to use Erlang on IBM Cell BE were frustrated by Erlang's memory. (Source)

And something closer to my heart, which, as I recall, I read after the ICFP contest:

Coding was very simple, translating pseudocode into C ++. I could use Java or C #, but I'm at a point where high-level programming in C ++ is just as simple, and I wanted to keep the option of quickly dropping to a few low-level bit-twiddling if it came to it. Erlang is my other favorite hacking language, but was worried about working a problem that I could not pull out from. (Source)

Answer 6

For me, the fact that Erlang is dynamically typed is what guards me. Although I use dynamically typed languages ​​because some of them are just very problematic (take Python, I solve a lot of problems with it), I'm sorry that they were not statically injected instead.

However, I intended to give Erlang a try for some time, and I was just starting to download the source. Therefore, your "question" still achieved something .; -)

Answer 7

A few reasons:

• Because it looks alien to anyone used for the C language family

• Because I wanted to be able to run on the Java Virtual Machine to use tools that I knew and understood (like JConsole), and the years of effort that went into JIT and GC.

• Because I did not want to rewrite all the (Java) libraries that I created over the years.

• Because I have no idea about the Erlang ecosystem (database access, configuration, assembly, etc.).

I am mostly familiar with Java, its platform and ecosystem, and I have put a lot of effort into creating materials that work on the JVM. It was much easier to switch to scala.

Answer 8

I know Erlang since graduation, but still have not used it in my own projects. Mainly because I mainly develop desktop applications, and Erlang is not a good language for creating nice GUIs. But I will soon implement a server application, and I will give Erlang a try, because that is what it is good at. But I'm worried that I need more libraries, so maybe I will try with Java.

Answer 9

I decided not to use Erlang for my project, which would run with a lot of shared data on one multiprocessor system and go with Clojure becuase Clojure really gets shared-memory-concurrency. When I worked on distributed storage systems, Erlang was very useful because Erlang really shines on distributed messaging systems. I compare the project with the best function in the language and choose accordingly

Answer 10

Used for a message gateway for a proprietary layered binary protocol. OTP templates for servers and the relationship between services, as well as matching binary patterns, made the development process very easy. For this use case, I would probably prefer Erlang over other languages.

Answer 11

JVM is not a tool, it is a platform. Although I am all inclined towards choosing the best tool for the job, the platform is basically already defined. If I do not develop something separate, from scratch and not wanting to reuse any existing code / library (three aspects that are unlikely to be isolated already), I can freely choose a platform.

I use several tools and languages, but I mainly focus on the JVM platform. This excludes Erlang for most, if not all of my projects, as interesting as some of its concepts.

Silvio

Answer 12

While I liked many aspects of the design of the Erlang runtime environment and the OTP platform, I found it to be a rather annoying programming language for development. Commas and periods are completely lame and often require re-writing the last character of many lines of code to change one line. In addition, some operations, simple in Ruby or Clojure, are tedious in Erlang, for example, to process strings.

For distributed systems based on a common database, the Mnesia system is really effective and probably a good option, but I program in the language to learn and have fun, and the annoying factor Erlang began to outweigh the weighty factor as soon as I got past the basic guides on bank accounts and started writing plugins for the XMPP server.

Answer 13

I love Erlang in terms of concurrency. Erlang really did concurrency right. I did not use erlang primarily because of the syntax.

I am not a functional programmer by profession. I usually use C ++, so I want to switch between styles (OOP, imperative, meta, etc.). Erlang seemed to make me worship the sacred cow of immutable data.

I like the concurrency approach, simple, beautiful, scalable, powerful. But all the time when I was programming in Erlang, I kept thinking that I would prefer a subset of Java, which forbade the exchange of data between the stream and the Erlangs concurrency model used. I, although Java could best limit the language to a set of functions compatible with Erlang processes and channels.

Most recently, I discovered that the D programming language offers the Erlang concurrency style with the familiar c style syntax and a language with several paradigms. I have never tried anything in common with D, so I can’t say a perfect translation.

So professionally I use C ++, but I do my best to simulate parallel applications, as in Erlang. At some point, I would like to give the D concurrency tools a real test drive.

Answer 14

I'm not going to even look at Erlang.

Two blog posts nailed it for me:

• The Erlang engine scans the entire list to see if they have a message to process, and the only way to get the message is to go through the whole list (I suspect pid message filtering also includes looking at the entire message list)

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

• There are no miracles, indeed, Erlang does not provide too many services to eliminate the inevitable overloads - for example, the application developer still has the task of checking the available space in the message queue (presumably, having passed the queue to find out the current length, and I believe that there are no built-in mechanisms to ensure some fairness between senders).

  erlang - how to limit a message queue or simulate it?

Both (1) and (2) are lower than the naive ones in my book, and I'm sure Erlang machines have more software gems of a similar nature.

So, there is no Erlang for me.

It seems that when you have to deal with a large system that requires high performance when overloaded, C ++ + Boost is still the only game in the city.

Now I will look at D.

Answer 15

I wanted to use Erlang for the project, because it is amazing scalability with the number of CPU's. (We use other languages ​​and sometimes hit the wall, leaving us the opportunity to customize the application)

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

A small operation excludes efforts to port and support the AIX version of Erlang and I ask our customers to use Linux for part of our application, this is not an option.

I still hope that AIX Erlang will arrive so that we can use it.