[erlang-questions] suitability of erlang

[Michael Truog]

On 10/11/2012 11:47 AM, Rustom Mody wrote:
> On Thu, Oct 11, 2012 at 11:12 PM, Joe Armstrong <erlang@REDACTED <mailto:erlang@REDACTED>> wrote:
>
>     I have no idea - you haven't told me what problem you want to solve -
>     you've told me the
>     technique you wish to use to solve the problem.
>
>     This is a bit "back to front" - I'd like to *start* with the the
>     problem then figure out how to solve
>     it - not *start* with the idea that you want FSMs and events and so on
>     and not tell me what the
>     problem is.
>
>
> Legacy system in C -- Sits on top of an event-oriented middleware.
> Since the C system is at core FSM-oriented, it is quite unstructured (from the normal programming POV)
>
> Ideally one should throw out the mess and start fresh with an appropriate technology, perhaps Erlang.
> Realistically, the stakeholders always prefer evolution to revolution.
> If not for anything else, just for unraveling the old-code semantics some re-engineering is inevitably required
>

There are 4 main ways to integrate Erlang and C/C++ source code:
- NIF
- port driver
- port
- cnode

The NIF and port driver approach can expose the Erlang VM to any memory problems the C code creates, though it is the most efficient.  Usually legacy C or C++ code is best integrated with a port, which is ran as a separate OS process communicating with pipes.  I have an open source project here: http://cloudi.org, which can simplify this integration and also provide natural scalability for your legacy source code if: you use the CloudI API (in this case, in C or C++) to communicate with an Erlang CloudI service that handles your external communication that needs to scale.  Then you can easily migrate parts of your system, or the whole system, over to Erlang, which will naturally improve your testing, debugging, scalability, reliability, concurrency and the source code size.  The integration is similar to integrating with an Erlang port, but it provides features that prevent integration problems, like:
- stdout/stderr handling
- automatic OS process failure handling (similar to supervisor restarts)
- request UUIDs
- requests as transactions (i.e., each request receives a response asynchronously)
- timeouts are enforced for soft-realtime constraints on the external software
- native language integration (both C and C++ have separate interfaces which provide the CloudI API)

As with all open source projects, it needs more documentation, but tell me if you have any questions.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121011/053deb38/attachment.htm>