| 1. I don't see how this is related to working with binary data. 2. Apparently you haven't worked with Erlang. The point here is you don't
write much networking, you write message handling exactly in the same manner
as you would for communicating inside the application, without any networking.
0MQ, WCF and JMS don't even remotely resemble the operation model for network
connectivity in Erlang. 3? (Let it crash) And you needed to specifically design your application,
including supervision (you do have it, right?). Erlang provides all that
already. 4. You didn't get what supervision is about. It's about restarting process
when it crashes, crashing all the related processes and aborting when
restarts are too frequent. > It's easier to get staff, It's easier to get some staff, but it may be much harder to get good
staff. Signal-to-noise ratio is very bad among Java programmers. And it's
quite hard to find bad Erlang programmer once you find somebody who can write
in Erlang (or learn it quickly). It's not that Erlang provides one specific killer feature that makes it great
choice. It's that Erlang provides plenty of nice things already built in, and
all that sums up to a platform that one would want to use every day. You don't
have good binaries syntax on top of JVM. You don't have good logging framework
in standard JVM. You still need external libraries for sensible network
programming. You have to design your application specifically to handle
thread failures. You can't just spawn a thread for every request running and
be done with the job. You don't have a distributed soft real-time database.
And the list goes on. You just need to do much work before you even start programming, and then to
manage all that (which is no easy task), just because your platform doesn't
provide any of the mentioned things and its working model is less convenient
for writing network services. |