zeromq v.s. erlang

 

https://stackoverflow.com/questions/12667983/erlang-vs-zeromqany-language-for-embedded-applications?r=SearchResults

zeromq是一個網絡庫，而erlang是一種語言，若是要比較，必須是比較erlang與zeromq+ a language 相比

You're comparing apples and oranges. Part of the advantage of using Erlang is the language; if you're going to put it up against zmq + some other language, the other language in that comparison really matters. zmq + ARM assembly? Erlang brings all the wonderful advantages of not hand-coding ASM.

 

個人觀點是，若是你用zmq的話，那你須要花不少精力開發異常處理模塊，可是erlang天生自帶這個，這是一個很大的優點

My point would be that you will have to work very hard to get the same kind of error handling in Zmq. Erlang has some really nice built-in error handling when things begins to go bad. There has been considerable time spent in Erlang optimizing that part and making it robust.

zmq是一個網絡庫，和一些語言使用的時候，某些項目上評分會很高，由於消息傳遞的開銷少，消息處理要快一些，比erlang而言

Zmq on the other hand, is probably faster in some combinations with some languages when you make simple benchmarks. There is less overhead, so it may process messages faster than what Erlang can provide.

可是作着作着，你須要重複造輪子，而這些輪子在erlang中早就有了，erlang已經超過15年了！（實際上已經30年了吧？）

But chances are that you will end up re-implementing large parts of Erlang in the language of your choice. And you will probably not do a job as good as 6-10 developers working on Erlang/OTP for 15 years.

不過呢，erlang很難學，哈哈，並且是函數式編程（在中興內部，屬於高級程序設計）

On the other hand, Erlang is not a simple language to learn. There is way more to it than just learning how to program in a functional style. Especially the concurrency patterns and failure handling can take some time getting used to.

 

 

https://www.rabbitmq.com/blog/2011/06/30/zeromq-erlang/

 

消息通訊機制的語義（share-nothing concurrency）

zeromq因爲是一個網絡庫，並不強制你徹底使用消息通訊機制，而erlang則從語言層面限制你只能使用消息通訊。

總的來說，erlang是一種語言，提供了很是多的機制，zeromq是一個輕量的網絡庫，提供一些通訊原語，pub/sub, req/rep, push/pull

 

I'm only passingly familiar with both. Could somebody clarify what this means? It sounds like gibberish to me at the moment.

"in Erlang, processes are values and message-passing channels are anonymous; in ZeroMQ, channels are values and processes are anonymous"

 

@Bryan By "values" I mean something that you can e.g., construct and assign. In Erlang you construct processes explicitly, and communicate by naming them:

P = spawn(fun() -> ... end), P ! message

How the communication happens is implicit.

With ZeroMQ, the communication channel is explicit -- I can (in Java, say), create and assign a thread, but I don't talk to it by naming it. Instead, I open a socket (and hope it has opened the other end). The communication channel is a value, and for the purpose of communication and often otherwise, the thread is anonymous.

 

一個評論指出，erlang是以程序設計語言爲中心的，最終用戶體驗很差，而zeromq設計不復雜，可是最終用戶體驗很是棒。指出使用zeromq在一週內，基於大量語言，均可以作出良好的分佈式產品，只須要一個小小的庫和一些API層就能夠了。

It is really not about the underlying technology, but the user experience. Technology is the basis for the user experience but cannot replace it. All language-centric solutions to software architecture (which form the majority of elite languages over the last decades) focus on technology and forget the user.

Erlang may be great. I don't know, I've never used it. My knowledge of it is second hand, and told to me by Erlang developers, who consistently love and defend it.

ZeroMQ is great. I do know, having used it in anger in many diverse projects now. My knowledge of it is based not on its implementation (which I admire but often fight with) but on its end user experience.

And here is the thing. You give ZeroMQ to random developers who are used to building stand-alone apps, or at best weakly distributed apps. You show them the power, help them design some protocols, and suggest some use cases. And it takes about 1-2 days, and their brains begin (if they are not zombified by too many years of the enterprise) to whisper and jump and shout, and out come ideas. And then, in hours (not days) those ideas turn into running code.

I've done this over and over. It doesn't require any switch away from known languages, tool-chains, plaforms. Just that little library, and some API layers. I just spent a week doing this, and we built prototypes of various distributed products, on Windows, Linux, Android, Mac OS/X, and HTML5. We worked in C, C++, Python, Java, JavaScript, and Node.js. We were seven, and we spent 5 days, and none in the room except me had tried or read about ZeroMQ before.

This is the end user experience. Simple, fun, an easy step from a known environment into a distributed future full of potential.

That is why ZeroMQ is not Erlang, nor any other programming language based vision of the future. No conversion required, you just add one more API to your stack, and BOOM! Your world changes.

I'd apologise for any simplification of Erlang that helped explain the point we were making about ZeroMQ's approach to multithreading, but then again, no. The point is that learning a new language just to proof some concepts is an impossible barrier for most people, in most cases. Does Erlang run on Android? In the browser? In my existing toolchain? In the brains I have in the room this week?

And if learning a new language to prove some concepts is impossible, it's finished. Erlang may be amazing (and I'm sure it is) but it's a dead language. As dead as Sanskrit. The future is Python, Java, Javascript, and C (and maybe still C++ though that is another elite language).

That is my view, anyhow, based on the observation that simplicity always beats functionality.

 

不過，java，有了一個erlang!就是

It looks like the Java world is getting their Erlang too:

http://typesafe.com

Typesafe is a combination of Scala and Akka to give Erlangy goodness to the JVM. Although when Martin Odersky and Jonas Boner are leading, you know it will definitely not be "informally-specified bug-ridden slow".

Another interesting example of a system that has spent a long time reimplementing Erlang is OpenCog.

http://wiki.opencog.org/w/About_OpenCog

It seems that OpenCog (and Novamente before 2008) have spent 10 years building a distributed conceptual graph in C++ together with many modules for AI processing. They did flirt with the idea of Erlang in 2009, but by then it was too little too late.

http://wiki.opencog.org/w/Erlang_Implementation_of_CogServer_and_AtomSpace

It's hard for me say how much of that time was spent on the infrastructure, as opposed to the AI bits, a guess of a 50/50 split might not be too far out, especially in the early years. But whatever the ratio, time spent rewriting distributed infrastructure is time not spent developing the core AI algorithms.

I think this supports Pieter's point that people choose what they are familiar with, and what is easiest to integrate with their target audience, even if they waste years doing it.

 

ZeroMQ =/= Erlang

Recently I saw a tweet saying "ZeroMQ Erlangizes everything!" or some such. While I realise that not everything posted on the web is meant seriously, it does seem there is a stream of similar claims lately that ought to be dammed.

In the article Multi-threading Magic[1], Pieter Hintjens and Martin Sústrik persuasively explain why concurrency is better served by message-passing than by locks and shared memory. And they are fair, I think, in their analysis -- except for the insinuation that using ZeroMQ transforms your chosen programming language into a domestic Erlang.

Mid-way through there is a sleight-of-hand. After mentioning the ingredients of Erlang, the article chooses just one of them -- message passing -- to be the key ingredient, and ignores the rest. But the others are at least as important! Let's look at all of them:

• Fast process creation/destruction
• Ability to support » 10 000 concurrent processes with largely unchanged characteristics.

A programming model where processes are lightweight values -- and a good scheduler -- make concurrent programming much easier, in a similar way to garbage collection. It frees you from resource micro-management so you can spend more time reasoning about other things.

• Fast asynchronous message passing.

This is what ZeroMQ gives you. But it gives you it in a form different to that of Erlang: in Erlang, processes are values and message-passing channels are anonymous; in ZeroMQ, channels are values and processes are anonymous. ZeroMQ is more like Go than Erlang. If you want the actor model (that Erlang is based on), you have to encode it in your language of choice, yourself.

• Copying message-passing semantics (share-nothing concurrency).

Notably, Erlang enforces this. In other languages, shared memory and the trap of using it (usually unwittingly) doesn't go away.

• Process monitoring.

Erlang comes with a substantial library, battle-tested over decades, for building highly concurrent, distributed, and fault-tolerant systems. Crucial to this is process monitoring -- notification of process termination. This allows sophisticated process management strategies; in particular, using supervisor hierarchies to firewall core parts of the system from more failure-prone parts of the system.

• Selective message reception.

You can use poll with ZeroMQ to efficiently use many channels in a single process at once; however, you don't get to block on particular kinds of message, meaning you have to buffer messages you don't want to deal with yet, or keep complex state around.

ZeroMQ is a lovely bit of kit, I would not argue otherwise. My point is that it does not magically give you fool-proof concurrent programming; neither does Erlang, but it's an awful lot further ahead than you may have been led to believe. With ZeroMQ there are still a number of things you have to invent, mimicking Erlang or otherwise.

[1] Multi-threading Magic. It's well worth a read.

This entry was posted on Thursday, June 30th, 2011 at 10:01 pm by Michael and is filed under Programming Languages. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.