Erlang Versus Python

[Samuel Tardieu]

| - Python internally do not have any network support, the
| CORBA/ILU/socket modules are system dependent, the no standard ways to
| connect to Python worlds over net (it's a couple libraries on the net,
| but none is a standard de-facto), the socket module presents on most
| platforms but you are having raw socket interface a-la old-good Unix and
| should take care about everything youself, Erlang - .... is;

There is no much difference between Python and Erlang, sockets are
accessed via a library, with a quite similar interface.

Python:

   s = socket (AF_INET, SOCK_STREAM)
   s.connect (("remotemachine", remorteport))
   s.send ("I am sending over the socket\n")

Erlang:

  {ok, S} = gen_tcp:connect ("remotemachine", remoteport, [])
  gen_tcp:send (S, "I am sending over the socket\n")

| - Easy access to the module internals (functions, classes, variables);

Being an Ada fan (in addition to Python and Erlang), I'm happy to get
some isolation. In Erlang and Ada, I can choose (using `export' and
a spec respectively) what I export. In Python, I can only choose
what I don't want to export and it adds an extra constraint (those names
must either start with an underscore or some extra code must remove
the binding for the functions I want to hide in the scope).

| - On-fly compilation (if the source was changed, the python going to
| recompile bytecode itself). This is really nice but dangerous feature,
| if the updated module contains bugs, all system are going to crash;

Just an extra note for people who do not know Python:
Python does not recompile anything that has been compiled already. I
mean, if you are editing a file and save it, the new version won't
be reloaded in applications that are already referencing it unless
`reload(module)' is used. As in Erlang, you can pre-load any needed
module provided you built a list before (the "application" file in
Erlang).

| - Erlang: functional development environment, with nice network
| capabilities, standard database and GUI, nice embedded possibilities for
| distributed computation. Pretty difficult to extend on C/C++.

You forgot "enhanced support for fault tolerance", which is quite
important to me (you can't guess how many people got impressed by seeing
the "application monitor" showing applications moving from one node
to another; I have even been asked to do an "Erlang applied to fault
tolerance" class for last-year students in ENST).

I understand your concern about extensibility. In spite of its lower
efficiency, I quite like the Erlang approach (ports or IC) which keeps
the "dirty" parts (compiled code) from corrupting the virtual machine.

If you trust the virtual machine interpreter for not crashing, and the
standard supervisor and friends libraries for having been extensively
tested, then you know that your application can last forever (ok, you
have to trust a few other things such as the hardware and the OS if any).

  Sam