Accelerating the Erlang system without slowing down the development

Recently, it became possible to use C to write modules for Erlang systems (this is more convenient for me than any of the methods proposed here ). Perhaps you did not know about the possibility of using Haskell in conjunction with Erlang. Haskell is obviously not a panacea and really critical parts of the code will probably still need to be rewritten in C, but Haskell offers strong typing and code reduction compared to C. I think it is easier to rewrite the code from Erlang to Haskell than to C, because both languages ​​are functional . Haskell is faster than Erlang due to static typing and a clever type inference system. I bring to your attention a free translation of an article about Haskell / Erlang-FFI .


Erlang types are represented in Haskell by ErlType type.
Type conversion is performed for types generated from standard ones using the toErlang function.
ghci> toErlang [("a", 1), ("b", 2)]
ErlList [ErlTuple [ErlString "a",ErlBigInt 1],ErlTuple [ErlString "b",ErlBigInt 2]]
ghci> fromErlang $ ErlList [ErlTuple [ErlString "a",ErlBigInt 1],ErlTuple [ErlString "b",ErlBigInt 2]] :: [(String, Int)]
[("a",1),("b",2)]

To create a node (node) with Haskel code, the createSelf function that accepts the node name is used.
self <- createSelf "haskell@localhost"

To create an erlang-style process (SIP), the createMBox function is used, which takes as a parameter the node on which the new process should be launched.

mbox <- createMBox self

In order to send a message, the mboxSend function uses 4 parameters: the hasle process that sends the message, the "name" of the Erlang node, the pid and the message itself. Post any type erlang. The Pid structure is somewhat more complicated: either Left pid, where pid is the erlang identifier of the process, or Right name, where name is the string with the name of the process.
')
mboxSend mbox node pid msg

It's easier to get messages:
msg <- mboxRecv mbox

There is also the possibility of higher-level interaction:

reply <- genCall mbox node pid msg

genCast mbox node pid msg


It is not difficult to guess that genCall makes a synchronous process call from gen_server to an erlang node, and genCast makes an asynchronous one.

You can also synchronously and asynchronously call functions from Erlang modules.

reply <- rpcCall mbox node module function arguments
rpcCast mbox node module function arguments


The possibility of linking processes, transferring errors, registering Haskel processes in Erlang Port Mapper Daemon is not implemented in this release.

Download here hackage.haskell.org/package/erlang .

PS Forgive me for not translating as a translation.