 |
lua-l archive |
|
|
||
|
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. Erlang is not a random fad for an example, it's a contender in the same realm, with an impressive history. To my knowledge the least academic of the FPLs. 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 |