[erlang-questions] Newbie - Erlang VS other functional languages

[Garrett Smith]

I don't think Erlang has an edge over any other language in terms of
scaling across multiple servers - not at all. Other functional
languages have access to network APIs the same way Erlang does.

I suppose it's less fiddly to send Erlang terms across the wire.
Erlang has some built in facilities for building distributed
applications. Erlang's been doing this sort of thing for a long time.
But other languages can do it - particularly with the many
multi-language messaging libraries and tools available today.

What Erlang is special for IMO is it concurrency model, which is
implemented in and enforced by the *VM* - there's no shared memory
across threads of execution. One thread cannot corrupt the memory used
by another. To communicate between threads of execution, threads must
pass and receive messages (copied data).

I use the word threads generically here - in Erlang they're called processes.

This changes everything. It's completely transformative of the way you
build software. But the real payoff is in your locally running program
and less so in the ability to "distribute".

Try building software using single threaded, isolated processes (no
shared memory). How do you do it? If you use Erlang, you're forced to
do it - there's no choice.

It's the same as the operating system level. How do you build a LAMP
stack? (sorry, I'm older then 24) You install independent components
(Apache, PHP (fork exec'd), MySQL). Then you configure them to work
together. Then you start them up in a particular order. It's
coordinated communication independent functions. If one blows up, the
others keep working.

Imagine every part of your program working like this and you have an
Erlang application - actually, an Erlang *system*.

To replicate this model at the OS level, you'd write dozens of small,
independent applications that communicated with each other over pipes
or sockets. The ZeroMQ community is familiar with this approach.

The payoff for this, as I see it, is flexibility and speed of
introducing new functionality and fixing bugs.

To illustrate at a higher level, imagine a smart phone today that
didn't provide isolation across applications. What would you expect
from it? I'd expect it to not work unless the applications were all
nearly perfect. That means it will either not work, or the app
ecosystem would be very limited. But today, smart phones all have
kernels and user space where apps are isolated from one another. So I
can install some random thing from an app store and have a pretty high
confidence that it's not going to ruin my phone. The result is *huge*
app ecosystems with phones that pretty much work (shockingly well for
what they're asked to do).

When you use Erlang, your program becomes this ecosystem of "apps"
that you can add to, modify, remove very freely without concern for
the whole system. Your program will be evolvable *and stable* in the
same way your phone is evolvable and stable. It's a scalable
programming model!

It's truly fantastic - and seldom mentioned. (Folks here have heard
this line from me before - this is my particular drum that I like to
beat on :)

Use Erlang!

Garrett

P.S. I routinely run into critical memory problems in Java apps that
host ecosystems of other "apps" (plugins). It's a completely
unsolvable problem when your language/VM encourages intractable memory
graphs across threads unless you are incredibly careful about what you
run. If you want to make a system pluggable in Java (in one JVM), be
prepared for it to stop working at some point. So your either limited
in what you can do (and how fast) or in the stability of your program.

On Fri, Jan 16, 2015 at 6:29 AM, Jesper Louis Andersen
<jesper.louis.andersen@REDACTED> wrote:
> I think your observation is correct.
>
> An Erlang program works by having many small processes, all isolated from
> each other. The way to communicate between processes is to send a message,
> asynchronously. This in turn leads to the key observation: when you send
> messages, you don't care about *where* the other process is. It could be
> local or on a completely different machine. The syntax and the semantics are
> the same, and you would program the system much in the same way. The
> environment is thus very homogeneous, compared to other solutions where you
> need to communicate on two levels: one for local messaging and one for
> distributed messaging.
>
> I also second Bob's observation: The design feature of being functional
> forces a lot of properties which are beneficial to programs where
> correctness matters more than squeezing out the last ounces of performance
> from a tight computational kernel. But there is more to it than that. A good
> example is the choice of standard data structures which have no pathological
> problems in corner cases. Or the deep continued focus on scaling to multiple
> cores rather than looking for efficient single-core performance.
>
>
> On Thu Jan 15 2015 at 11:38:52 PM Bob Ippolito <bob@REDACTED> wrote:
>>
>> I'd agree with that observation. Erlang is particularly well designed for
>> reliability and ease of maintenance/debugging. I wouldn't necessarily say
>> that these properties are due to the language, it's really the environments
>> that Erlang has been deployed in that shaped the VM and libraries in this
>> way. The tooling and libraries have at least a decade head start for this
>> kind of industrial usage over just about any other functional language.
>>
>> On Fri, Jan 16, 2015 at 9:01 AM, Ken Wayne <kwayne@REDACTED> wrote:
>>>
>>> I've been investigating functional languages and the concepts that lead
>>> to increased speed, reliability, and decreased maintenance.  Erlang seems to
>>> have a distinct advantage over other functional languages when you need to
>>> scale across multiple servers because it's a natural part of the language.
>>> Can anyone confirm/deny or elaborate on the observation?
>>>
>>> Without wax,
>>> Ken Wayne
>>> kwayne@REDACTED
>>> Desk: 715.261.9412
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>