Speed ​​up Erlang systems without slowing down development

Recently, it became possible to use C to write modules for Erlang systems (in my opinion, this is more convenient 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 sections of the code will probably still have to be rewritten in C, but Haskell offers strict typing and a reduction in the amount of code 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 thanks to static typing and a smart 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 the ErlType type.
Type conversion is carried out for types generated from standard ones using the toErlang function. To create a node (node) with Haskell code, the createSelf function, which takes the name of the node, is used. To create an erlang-style process (SIP), use the createMBox function, which takes as a parameter the node on which to start the new process. In order to send a message, the mboxSend function accepts 4 parameters: the process that sends the message has fused, the "name" is the erlang of the node, pid and the message itself. Post any type of erlang. The Pid structure is somewhat more complicated: either Left pid, where pid is the identifier of the process erlang, or Right name, where name is the string with the process name. Getting messages is easier:
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)]


self <- createSelf "haskell@localhost"



mbox <- createMBox self



mboxSend mbox node pid msg


msg <- mboxRecv mbox

There is also the possibility of a higher-level interaction: It is not difficult to guess that genCall performs a synchronous process call from gen_server to an erlang node, and genCast - asynchronous. It is also possible to call functions from Erlang modules synchronously and asynchronously. The capabilities of linking processes, transferring errors, registering process huskels in Erlang Port Mapper Daemon are not implemented in this release. You can download it here hackage.haskell.org/package/erlang . PS I'm sorry I did not issue it as a translation.

reply <- genCall mbox node pid msg

genCast mbox node pid msg






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