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:
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.