Language Bindings for Erlang Again (Opinion)

[Rick Pettit]

On Mon, Jun 05, 2006 at 05:40:19PM -0700, Jeff Crane wrote:
> > > > Basically, it sounds like you are inventing
> > > > problems
> > > > where there aren't any. Why?
> 
> Erlang is not some utopian language. There must be
> large or multiple problems to prevent adoption when
> implementing the most trivial of tasks. First, Erlang
> is not adopted because it is not exceptionally good at
> satisfying basic project goals like speed,
> maintainability, and efficiency.

Really?

> In small standalone programs, it's unlikely that anyone would consider
> Erlang over a purely interpreted language.

I'm not sure small, standalone programs fit the problem domain Erlang is
best suited for.

> As an employer, it's near-impossible to find a person to
> maintain or support my new Erlang project in any
> State, much less my County.

This, sadly, is true. I bet you could find a thousand really terrible Java
programmers for every 1 decent erlang programmer (but that's just a guess).

> The amount of Erlang the average programmer (me) needs to write to perform
> the same work as 12 lines of ASP, is beyond reasonable.

I'm pretty sure that the ASP and Erlang don't qualify as solutions in the same
problem domain.

A good erlang programmer can write in 10 lines what might take 100 lines in
a language like C/C++ or even Java. But again, it all depends on the problems
you are trying to solve.

For building concurrent, distributed, fault-tolerant systems I haven't found
anything that beats Erlang.

> The difficulty in bridging to other languages is what
> stifles adoption within my peer group. I have no
> examples of Erlang binding nicely to anything but C++.

J-interface for Java? PyErlang for Python? Erl_interface/ei for C/C++?
You can find information about these off the Erlang website and after about
30 seconds on google.

We use J-interface and erl_interface/ei both in production with great success.

When calling out to some other process in Erlang a quick-and-dirty method 
might be to spawn the foreign interpreter, etc, as an erlang port. We have
done this with perl and expect scripts before, for example (again in 
production systems with much success).

> A month of digging and posting in my free time (that
> 99% of Erlang dabblers will not bother with
> regardless), I still dont have Erlang talking to
> Python (which I'm also learning).

I googled for "erlang python binding" and the first entry returned was:
http://starship.python.net/crew/gandalf/PyErlang/

That said I don't know much about it. I also didn't bother to see what other
links were returned (but then again it isn't a problem that I personally am
trying to solve).

> Personally, I'm using Erlang for its strengths. Is it
> better than RakNet? It's certainly easier to
> implement! and that's worth something...but it's not
> exactly presented as a prototyping language.

Erlang is an excellent protoyping language, especially with its great support
for loading new code into a running system on-the-fly. We have used this
feature both to toss up a skeleton server and add functionality w/out downtime
as well as to patch bugs in production systems requiring 24x7 uptime.

> I first bought into the advantages of Joel Reymont
> when he presented findings through the OpenPoker
> project. I also examined the criticisms, which were
> never really addressed. Anyone can whip up a large
> program that passes numbers around registers and point
> out "see how fast it is". How scaleable, realtime, is
> a large Erlang program? Where are the performance
> tests over 100m of cat5? I'll test it myself and then
> I'll know.

I'm not sure what more to say. There is a learning curve involved with Erlang,
like anything else. Perhaps the learning curve is a bit more steep as there
are so many foreign concepts (single assignment, functional programming
paradigm, etc). In my case the benefits have greatly outweighed the cost of
learning.

-Rick