I'm only passingly familiar with either, but it seems like most of what ZeroMQ offers is already built into Erlang, yet there's an Erlang-ZeroMQ binding that's fairly active according to its github page. What am I missing?
ZeroMQ in Erlang – Benefits Over Native Erlang Capabilities
erlang
Related Solutions
Other than the fact that Erlang was specifically developed to be run in concurrent/parallelized/distributed situations, the two main techniques that it employs making this possible are:
No side effects
This means, when you give a function a piece of data to execute against, it will not except in very strict cases affect anything else in the system/running process. This means that if you execute a function 300 times all at once concurrently, none of those 300 executions of the function will effect any of the others.
The implementation technique for ensuring no side effects is called "immutability" which roughly means, may not be mutated(changed). This means that as soon as you create a variable, the value of that variable may not be modified. Erlang implements this behavior with "single assignment" so after you assign a value to a variable, you may not assign a value to it again.
X = 1.
X = 2. // This is not a valid operation
This ensures no code may accidentally change the value of X causing a race condition, therefore it is inherently thread-safe and concurrent use becomes trivial. This is a very uncommon behavior among software languages and the biggest way Erlang manages to be so well suited for concurrent execution.
The actor model
This is a particular way of modelling that has shown to make the implementation and management of concurrent processing very simple for developers. Straight from Wikipedia:
The Actor model adopts the philosophy that everything is an actor. This is similar to the everything is an object philosophy used by some object-oriented programming languages, but differs in that object-oriented software is typically executed sequentially, while the Actor model is inherently concurrent. An actor is a computational entity that, in response to a message it receives, can concurrently: send a finite number of messages to other actors; create a finite number of new actors; designate the behavior to be used for the next message it receives. There is no assumed sequence to the above actions and they could be carried out in parallel. Decoupling the sender from communications sent was a fundamental advance of the Actor model enabling asynchronous communication and control structures as patterns of passing messages.
There are a few things that Erlang does to help with these.
- Data is immutable, so no data races
- OTP gen_servers and gen_fsm's provide a very well tested pattern for servers
- Supervisors allow for recovery from crashes
- processes are small and cheap
- Memory is allocated on a per process basis (no GC freezes)
- the erlang VM is optimised to work under very heavy loads
- Software can be updated on the fly, so no upgrade downtimes
The major thing here is that in Erlang there is no shared state that could require a lock, so there is no need for locks. It is a brilliant language for soft real time applications that need no downtime and high fault tolerance and concurrency
Best Answer
ZeroMQ bindings are available for a lot of programming languages, not just Erlang; this is one of the library's great strengths.
Erlang's built-in mechanisms are probably great as long as everything uses Erlang, but I doubt they are in any way compatible with other languages' native networking mechanisms.