[erlang-questions] The future of Erlang and BEAM

[Tim Watson]

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.

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.

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.

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.

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.

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.

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.

On 13 February 2012 03:17, Deryk Barker <dbarker@REDACTED> wrote:

> 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...
>
> 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:
>
>    the fact that erlang is a functional language.
>
> 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.
>
> 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.
>
> Besides, I think java is a terribly *ugly* language...:-)
>
> deryk
> --
>
> Deryk Barker, Computer Science Dept.
> Camosun College, Victoria, BC, Canada
>
>
>
> ______________________________**_________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120213/e16e1c99/attachment.htm>