[erlang-questions] Why do "interface to language X" projects all seem to die out?
Wed Aug 31 17:50:30 CEST 2016
On Wed, Aug 31, 2016 at 10:36 AM, Tuncer Ayaz <> wrote:
> On 31 August 2016 at 16:18, Matthias Lang <> wrote:
>> Pretty much all of the "not built in to OTP" ways to connect to other
>> languages seem to have died, i.e.
>> - EPI (C++). Last commit 2009.
>> - py_interface (Python). Last commit 2014. Freshest of the lot.
>> - edtk (C). Last release 2007.
>> - dryverl (C). Last release 2008.
>> - erlua (Lua). Project page dead. Author's email is dead.
>> - erlualib (last commit 2010). Github-linked company page dead.
>> Can anyone offer some experiences or ideas why?
>> Could it be that these types of solutions are rarely needed? Maybe
>> NIFs are unbeatable for the "narrow interface, no state, high
>> performance" cases and port programs with hand-rolled interfaces most
>> of the rest.
> https://hackage.haskell.org/package/erlang (alive)
> https://github.com/jlouis/erlangnode (alive; not sure how complete)
> https://github.com/EchoTeam/ocaml-erlang-port (very stable or abandoned)
> erlang-questions mailing list
I think in these distributed scenarios the go to protocol is something
language agnostic like something-over-http.
Personally I would not go around trying to get other languages to
speak the Erlang wire protocol. I've used the Java libraries to build
nodes and they worked, but I wouldn't do it again. Instead I'd use
something like 0MQ or again the ponderously inefficient but ubiquitous
If I need to integrate with other languages more closely, I'll use the
port interface. Here's a terrific example of how that can be extended
into various lanauges:
Unless a NIF is simple and well established as non-crashy, I'll write
performance critical code as a C port. People don't like this because
of the emotionally crushing thought of serializing data over stdio.
While that's laughably inefficient when compared to zippy NIFs
(troll), the code remains isolated and can crash all it wants without
bringing down the entire VM. It also encourages an interface design
that minimizes IO -- you performed as much work as you can on either
end and pass small results back and forth.
More information about the erlang-questions