Peace and let's say no to flame wars, comrades! Don't get me wrong, Java is an awesome language, but if you have already started serious coding in Erlang, you will probably never look back. Or maybe you will occasionally, like I did few days back, when I was charged with the task of cloning ejabberd module by replacing mnesia with odbc calls.
It might sound like fairly routine task, and it was for the most part, except sometimes it's hard to reason about Erlang function output just by looking at the source code. Java methods, on the other hand, always have statically typed output, which obviously eliminates any guessing work. So, after few attempts trying to mentally trace some of mnesia transactions, I suddenly felt my brain overloaded and had to resort to debugging ejabberd from remote node :-) I had to recompile the module with -compile(export_all) in order to be able to try functions that contained mnesia code in Erlang shell and figure out their exact output. This, of course, is an intrusive action and assumes the source code is available.
It could have been much easier, though, if the code was accompanied by documentation markup. Having function specifications will hugely help anyone who will ever have to work with the code, including the owner. I'm now ready to make resolution to have specifications for every single function in my code, including non-API functions. By the way, exmpp team really impressed me by thoroughly following this path throughout entire code base.
To me, having to have function specs in the code, while being a good thing on its own, is a very small price for the feeling of liberation and increased performance that dynamic typing in Erlang gives you compared to a static one in Java.
In conclusion, check out much more comprehensive discussion of typing problem in Erlang.
