[erlang-questions] Why do "interface to language X" projects all seem to die out?
Wed Aug 31 20:49:29 CEST 2016
On 08/31/2016 08:50 AM, Garrett Smith wrote:
> 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.
> erlang-questions mailing list
Based on https://github.com/hdima/erlport/issues/15 erlport isn't accepting changes and is dead.
More information about the erlang-questions