[erlang-questions] Why do "interface to language X" projects all seem to die out?

Loïc Hoguin essen@REDACTED
Wed Aug 31 19:26:17 CEST 2016


On 08/31/2016 05:50 PM, Garrett Smith wrote:
> On Wed, Aug 31, 2016 at 10:36 AM, Tuncer Ayaz <tuncer.ayaz@REDACTED> wrote:
>> On 31 August 2016 at 16:18, Matthias Lang <matthias@REDACTED> wrote:
>>> Hi,
>>>
>>> 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
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>
> 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
> something-over-http.

I wouldn't dismiss HTTP as inefficient. It's inefficient for RPC, which 
is how most people use HTTP (even when they call it REST). But if you 
use HTTP entirely then you have the options of caching proxies and 
caching on the client side that can easily be plugged in and get rid of 
most issues (other issues being largely fixed by HTTP/2).

-- 
Loïc Hoguin
http://ninenines.eu
Author of The Erlanger Playbook,
A book about software development using Erlang



More information about the erlang-questions mailing list