The "fit" and "not fit" of Erlang.

This is a creation in Article, where the information may have evolved or changed.

Erlang is now being vigorously promoted within the system. However, it is regrettable that the implementation of Erlang before the language itself is not in-depth argumentation and research, but by the core staff wrote a simple can not be a simple demo, in the project with an open-source Erlang project. From the engineering point of view, this is not reliable, in order to make the use of Erlang more reliable, so here a little nonsense. The data comes from the official Erlang and my guess, right up to me, believe it or not.

First look at the content from the Erlang FAQ (your own translation, not necessarily accurate, can see the original: http://www.erlang.org/faq/introduction.html#1.3):

——————————————————

What are the 1.3 Erlang items that are particularly suitable for use?

Distributed, reliable, soft real-time concurrency system.

* Telecommunications systems, such as control switching or protocol conversions

* Internet application server, such as mail transfer agent, IMAP-4 Server, HTTP server, WAP stack

* Telecommunications systems, such as the switch to handle mobile networks or the publication of unified format messages.

* Database applications that require soft real-time functionality

Erlang has a clear scope for dealing with problems when it was originally designed, so Erlang has a good performance in dealing with some problems. Here are some of the characteristics of this type of problem:

* Erlang provides simple and effective exception control and fault tolerance mechanisms (supervised processes).

* Concurrency and messaging are built-in mechanisms of language. Apps written using Erlang typically maintain hundreds of or even thousands of lightweight processes. The cost of context switching for the Erlang process is typically one to two orders of magnitude less than the thread of the C program.

* It is easy to develop applications that run on different devices, such as distributed applications. The distributed algorithms for Erlang are transparent: programs do not need to know that they are distributed.

* The OTP Library provides support for the general functionality of many network and telecommunications systems.

* The Erlang Runtime environment (a virtual machine, a Java-like virtual machine) means that the code "compiles once, runs everywhere". At the same time, the runtime system allows the running system to be updated without interrupting program execution.

===========================
What is 1.4 Erlang not a particularly suitable project to use?

Surprisingly, the user uses Erlang in all possible places, an example is communication with X11 at the protocol level, but in some cases Erlang is not the language to be selected.

The most common "unsuitable" problem is that performance requirements are the most important, and objective factors have a significant impact on performance. Representative examples are image processing, signal processing, sorting of large amounts of data, and underlying protocol interrupts.

Another category of problems is the large number of C code involved. A representative example is the implementation of operating system device drivers.

Most (all?) Giant systems developed using Erlang may use a lot of C on the underlying code, leaving Erlang to manage parts that tend to be complex in other languages, such as controlling the distribution of systems on several machines and implementing complex protocol logic. (This translation is questionable, in this case, do not use Erlang, for their own realization?) Or is it managed by Erlang? ）

——————————————————

If I'm not mistaken, the FAQs reveal a message that Erlang's goal is primarily to use applications such as mass communications. For high concurrency Data flow I/O should be a good choice (e.g. gateway, data exchange, etc.). For complex business logic processing or high-performance numerical computations, it is not a good practice (such as game logic in the game).

But I have a very old document here (it should be 2006 or 2007 years) to show that using a multi-language hybrid Erlang application may not be as efficient as a pure Erlang application. The main reason is that the switching overhead of Erlang's lightweight process is much less than the process switching overhead caused by communication with other programs.

All right, that's a lot of crap. The internal promotion of Erlang did not have this information, but I think it is very meaningful:

An Erlang-based MMO engine: http://sunweaver.blogspot.com/

Writing an Erlang-based MMO server: http://www.devmaster.net/articles/mmo-scalable-server/

An Erlang-based MMO architecture: http://www.next-gen.cc/

A discussion from the above MMO architecture: http://news.ycombinator.com/item?id=981597

Another discussion about Erlang's application in MMO: http://www.blitzbasic.com/Community/posts.php?topic=75515

Oh, yes, another recommended material, about go: http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the_project

Go should say that in some ways make up the short board of Erlang ...

February 28 Supplement:

Tim has done a good job of testing for C (nginx), Erlang, Java, and Go: The http://timyang.net/programming/c-erlang-java-performance/test is complete, but the following Comments more exciting! It would be nice if someone in the system could do something like this convincing when it comes to promoting new things.

In addition, in Tim's comments someone gave this thing http://www.javaeye.com/topic/107476 although it was years ago, but also very valuable.

However, the individual thought, of course, good language can be more powerful, but in the current project expectations of concurrency and load, language selection is definitely not the bottleneck of the technical nature ... Oh......

March 2 Supplement:

Old Article one article: Http://www.javaeye.com/news/3510-joel-reymont-of-complaints-erlang

The article itself is nothing, some of the ideas and ideas may be updated after so many years, but a friend in the comments said very well: " not a game system is well divided into different subsystems, his approach, regardless of the language used, to the last system expansion, there will be a lot of trouble "There is not enough experience in system planning, or there is not enough investigation and analysis ", " using oo thinking to do Erlang is a directional error, and Erlang does not support Oo ".

This friend's comment, just say that we have committed, or are committing, even will make the mistake !!!

March 3 Supplement:

On the subway today, I suddenly realized that I didn't care about architecture and demanded performance. That is, they who do not understand workers, perfork, and require multicore. Do! Erlang is the best choice. It's even the only option!

March 7 Supplement:

Powerful python, an Erlang node implemented in Python: http://www.lysator.liu.se/~tab/erlang/py_interface/. Oh, yes, after studying Erlang as a whole, it is not the language of Erlang that needs to be found in the system, but the architecture of Erlang. That is, the need for a programmer transparent distributed computing architecture, called ...