[erlang-questions] Erlang is the best choice for building commercial application servers

[Michael Truog]

On 03/12/2012 11:14 AM, Felix Hamilton wrote:
> An interesting data point that might be relevant here is that I have seen Erlang/OTP getting more traction in the 'big data' world recently. One really nice architecture seems to be to use Erlang for 3C stuff (command, control, and communications), something like 0mq to handle messaging, and Python (or something with similar user friendliness, readability, and popularity) to do user facing stuff and provide user scripting capabilities. This seems like a *really* powerful combination to me, and one that has arisen spontaneously in very disparate areas with completely unconnected developers. As a user of both Erlang and Python, there really doesnt seem to be a lot of overlap between the two, and using both buys pretty comprehensive problem space coverage cheaply and cleanly. The disco project ( http://discoproject.org/  ) is a great example most folks might be familiar with, but many others seem to be mostly closed source or 'software as a service' deals so far. ;-)
>
> Anyhow, that was a pretty interesting data point for me. You might not have to convince folks to let you write everything in Erlang if you can let all the user facing stuff use something they are more comfortable with and focus on using Erlang for 3C (where it really shines in my opinion) ... 
>
CloudI (http://cloudi.org) hasn't been mentioned yet, but is directly relevant since it acts as an application server and is implemented with Erlang.  CloudI provides ZeroMQ integration along with Python, Ruby, Java, and C/C++ integration.  The project is currently alpha and will be moving to beta soon.

The project provides a nice way of wedging Erlang into a stack so that you don't necessarily have the problems previously mentioned when introducing Erlang to people.  You can just take external code, convert it to using the CloudI API for major data messaging, and use the configuration to control the amount of processes/threads for scaling the service.  Then, it becomes much simpler to show the benefits of Erlang, since you can replace parts of the system with Erlang, using CloudI services that take over various functions (advertised based on the service name) and improve upon the codebase without forcing anyone into a major rewrite.  That reduces any development/business risk when developing with Erlang.  The approach would be for people making a production system, not just for prototyping, though it can also help facilitate easier prototyping with diverse libraries that need to be used in a fault-tolerant, scalable way (with a consistent interface).

- Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120312/285ccf00/attachment.htm>