On 6/23/11 5:29 PM, Lorenzo Donati wrote:
... welcome to correct me! :-)
Ok then, further OT I guess, both for
* avoidance of shooting in your own foot and
* error handling,
maybe take a look at Erlang for the future.
Since the advent of multi cores, Java has lost the safety edge. Resource
deadlocks in truly parallel environments became the new Achilles Heel of
systems and Java has no built-in way around it. Like Java prevented C's
pointer crashes, by design, Erlang prevents programmers from dead locking.
In a nutshell, it allows no shared memory between processes and that is
that. But just like Java still knows undefined pointers, you obviously
can produce dead locks and races in Erlang, but not in the usual
contentious ways.
Especially because Java Systems can be huge, a race that kills the VM,
only once in 24h, is just a nightmare. I knew one $$$ million company
that just restarted their Java servers every night because they couldn't
locate the leaks from it. That's Java reality today, on multi core machines.
Also Java's way of catching errors, tediously, is not the only way.
Erlang has the philosophy to 'just let it crash' and a totally different
approach to recovery, which saves the functional code from being
overwhelmed and littered by defenses ten times its size. Erlang, in a
way, handles the unforeseen as well as the expected problems, which is
not what Java's statically typed Exception model would promise.
Somewhat back on topic: Erlang has no type system and some extremely
bright people failed at giving it one when they tried. But it has an
excellent static analyzer that catches type errors of even composite types.
And, Erlang has a VM, and programs are compiled to bytecode but can also
be interpreted from source - then some years ago it got a native
compiler that speeds things up nicely. That compiler gives speed ups of
up to around 10x. To get to that, it translates the VM bytecode into
native machine code and bends the call table to the new code.
Henning
