<div class="gmail_quote">Java is ugly and bloated to boot. The JVM though, is actually a pretty fantastic piece of engineering and if you dig into the guts of it, there's a lot that VM teams across the board can learn, especially around self tuning and diagnostic/instrumentation support.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">I think the point about Michael made about mind-share is a very good one. Also the Java platform, for all its bloated complexity, is more mature in some respects. What I mean by that is, for developing typical business applications, Java (and god forgive me for saying it, the other big unmentionable corporate platform too) offers a number of things that are very beneficial and currently lacking from Erlang's ecosystem. For example, JDBC offers reliable and high performance connectivity to almost every database on the market. There are standardised APIs for working with things like web servers and this makes a big difference to the productivity of *ordinary programmers* who are the target audience for these kinds of development platforms. </div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Having said that, I'd pick Erlang and fiddle with API inconsistencies and the near suicide inducing pain of ODBC on unix any day over Java.</div><div class="gmail_quote">
<br></div><div class="gmail_quote">Going back to what the OP was asking: One of the reasons I don't think that we'll see a competitive implementation of Erlang on the JVM any time soon is that the JVM was built, first and foremost, to host an imperative language. Now the appearance of Clojure does prove that you *can* implement a functional language on the JVM, but Erlang is not just a functional langauge/platform, it is also (as Joe has put it) "Concurrency Orientated", which is about the lightweight Process being a fundamental and first class concept. Java does not have micro/green threads and native threads have limitations. The JVM does not, at its core, support the notion of immutability that we have in Erlang, despite good support for copy-on-write semantics in some (limited) circumstances. </div>
<div class="gmail_quote"><br></div><div class="gmail_quote">The scala crowd can build 'actors' and 'message passing' into their libraries, but these concepts are not part of the JVM. Developers of Scala/Clojure code *can* make their variables, types (and so on) immutable, can implement a syntax for passing around chunks of code in order to imitate higher order functions, but these concepts are not (as of today) part of the JVM. The core concepts for the JVM (and the CLR) are Objects with 'mutable state', native (os level) threads and in Java's case, primitive types that are distinct from objects. You can't get away from those underlying concepts in reality, so 'actors' are Objects and 'message passing' is done by sharing (object) state on a heap and so on.  </div>
<div class="gmail_quote"><br></div><div class="gmail_quote">One of the problems people *seem* to be trying to get away from by moving to the JVM is that of raw throughput. We might see a shared heap appear in BEAM some time in the future, for certain special cases, and maybe other optimisations for performance will occur. But as Joe and others have pointed out, Erlang was never built with this in mind. And yet I'm not convinced that an Erlang implementation running on the JVM will really offer great performance benefits, because in order to be *truly like* Erlang, that implementation would *have* to recreate the BEAM emulator running on the JVM. Languages like Scala (and maybe Clojure, I don't actually know) compile down to Java byte code, which means that they're really just syntactic sugar with some runtime library support around it. Perhaps the innovator behind Erjang will pipe in and correct me, but my guess is that you couldn't do that with Erlang without loosing so much of what the langauge/platform is all about. Therefore you're now running a complex runtime environment (i.e., the BEAM emulator) inside another complex runtime environment (the JVM), and fun though they are, the implementations of Jython and JRuby demonstrate that there is a great cost (in terms of performance) when you do this.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">I'm happy to be proved wrong, but for all the good engineering that resides in the JVM, I suspect it's probably not the right platform for a competitive Erlang/OTP implementation. </div>
<div class="gmail_quote"><br></div><div class="gmail_quote">On 13 February 2012 03:17, Deryk Barker <span dir="ltr"><<a href="mailto:dbarker@camosun.bc.ca">dbarker@camosun.bc.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As a mere amateur in the erlang world - I've used it a few times in my network programming course, probably bending the rules slightly to do so...<br>
<br>
But I've been programming for a while (first program FORTRAN on an IBM 7090 while still at school in 1968, second program in BASIC on a PDP-8 while taking a course from Maurice Wilkes at Cambridge in 1970) and there's one aspect in all of this thread that has either not been mentioned or at least not made much of:<br>

<br>
    the fact that erlang is a functional language.<br>
<br>
For years FP got a bad press, from the early days when the accusation was inefficiency ("LISP programmers know the value of everything and the cost of nothing") to the more recent criticisms that FP is very nice for academics but won't work in the *real* world.<br>

<br>
Erlang clearly blows these ideas out of the water and combines all of the attributes everybody else has mentioned with those of developing in a functional language, with all of its associated benefits, especially of correctness.<br>

<br>
Besides, I think java is a terribly *ugly* language...:-)<span class="HOEnZb"><font color="#888888"><br>
<br>
deryk<br>
-- <br>
<br>
Deryk Barker, Computer Science Dept.<br>
Camosun College, Victoria, BC, Canada</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>