Language Bindings for Erlang Again (Opinion)

[Thomas Lindgren]

--- Jeff Crane <jefcrane@REDACTED> wrote:

> > > > Basically, it sounds like you are inventing
> > > > problems
> > > > where there aren't any. Why?
> 
> Erlang is not some utopian language. 

Noone claimed that. My comment concerns the specific
problems posed by the OP.

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

Perhaps the small standalone tasks are better served
by a scripting language like Perl, Python or Ruby in
that case?

There was support for stand-alone Erlang for a while,
but this seems to have withered away. Part of the
reason was probably because it wasn't very easy to
start using it. On the other hand, scripting isn't
used much for Erlang's historical application domain.
Perhaps the demand was small too.

> 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 is what I consider a real Erlang problem: it is
fairly obscure. I'd furthermore expect things are
worse in the US. (Some consider that a competitive
advantage, of course. Not I.)

I'd like to see some good books on "modern erlang/otp"
for example. 

> 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'd recommend using the appropriate tool for the task
at hand. (Are you using Yaws, by the way? It's not
nearly as smooth as ASP, but it simplifies generating
dynamic content.)

> 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.

Clearly these factors depend on the program as well as
the language. 

The experiences so far, as far as I know and as far as
I can summarize, are that skilled teams can do
remarkable things. Productivity is quite good (4x
productivity of C++ according to Ulf Wiger at
Ericsson). I have seen Erlang used for commercial
purposes in teams ranging from a handful to nearly a
hundred people. 

Performance is normally competitive or excellent for
intended tasks. (Scientific computing is better done
in Fortran, say.) Programming for all-out performance
is probably better done in C/C++, at least if the
developers are skilled. 

System scalability is normally excellent compared to
simple thread-based solutions. In essence, the Erlang
runtime system "under the hood" is event-based, a
programming principle which has turned out to be very
robust in the face of high load.

Best,
Thomas


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com