[erlang-questions] FPGA coming around the corner

[Attila Rajmund Nohl]

2011/1/7, Edmond Begumisa <ebegumisa@REDACTED>:
> On Fri, 07 Jan 2011 22:58:50 +1100, Attila Rajmund Nohl
[...]
>> Erlang is not a "silver bullet for multicore".
>
> I don't think it is either! My point was parallelising parallel-able code
> is much much easier in Erlang than some of the options being offered up
> for the same purpose in other programming environments. It's as though the
> Erlang team has done most of the heavy lifting regarding SMP for you so
> you don't have to go looking at "transactional boosting."

In a previous project I was working on, we had a C++ server
implementing some CORBA functions. Some stub code had to be generated
from the IDLs, then our code had to inherit from these generated
classes. The orber run all requests in a separate thread - essentially
we got parallelism for free (i.e. no extra programming necessary).

We also had a Thread class, so when something had to run in the
background, the code was put in a separate class that inherited from
this Thread class and we just had to call it's start function. This is
not unlike what I had to do in Erlang when I write a new gen_server...

In my experience parallelism does not differentiate Erlang from other
languages. At first glance the message passing seems to be radically
different to function calling, but I very very very rarely use the !
operator, 99.99% of the cases it is hidden behind a gen_server or
gen_fsm:call.

What makes Erlang different from other languages is its VM. Hot code
loading makes compile&test cycles blazingly fast - you don't even have
to restart the application to test the changes! Not to mention that
the live system can be patched (useful for the many 9s reliability). I
think the real productivity gains from Erlang come from this fact, it
doesn't have to do anything with the language.

The ability to connect to live systems and poke around their internals
helps debugging greatly. I've just spent half an hour investigating a
deadlock situation (which turned out to be not a deadlock after all,
just a slow TCP stack) using erlang:process_info, sys:get_status and
friends to get the state of the system. It is much harder to do on a
C++ software with e.g. gdb (especially when there's no gdb at the live
system for security reasons). I don't know the scriptability of gdb,
but in the Erlang shell you can write - well, Erlang programs, which
is dead useful if you need to find 1 process out of 100s.