[erlang-questions] Erlang is the best choice for building commercial application servers

[Tim Watson]

On 14 March 2012 18:55, Jan Burse <janburse@REDACTED> wrote:
> Hi,
>
> The benchmark says nothing about the language design.
> The language design is very neat. It says something
> about the compiler backend and the runtime system.
>
> Probably the meme that Erlang outperforms Java has
> reached life cycle end. Since Java is quite old
> (born 1995) one would expect that they have already
> pushed the limits in speed.
>
> But the boundaries have changed. When transitioning
> from 32-bit to 64-bit (more registers), and from JDK 1.6
> to JDK 1.7 (better backend and runtime) I observed a
> speed up factor of 2.6. Same application and same
> hardware, just using a different JVM.
>
> So the competition is on. Maybe there will be a new
> beam interpreter in a few years, that can keep up
> with the development. Hint: The newer CPUs don't
> like branches.
>
> So threaded byte code interpreters, even with
> big instructions don't make much sense. Must go
> native code generation.
>

Of course we have HIPE for native code, but personally I don't
actually know what kind of code it generates - must go and read up on
it. I've seen a lot of these kind of arguments in numerous languages,
some with a VM (like Java and .NET) and others (such as OCaml,
Haskell, etc) without. JIT compilation is pretty powerful stuff, but
I'm not actually convinced that's why you see such great throughput on
the JVM - I suspect it has a lot more to do with mutable data being at
the heart of the VM design and being able to utilise efficient
swapping operations such as CAS.

Also there are pros and cons to having a VM at all. Well written
Haskell can have much better performance and throughput
characteristics than the JVM for many applications, compiled straight
down to native code without some additional runtime support generated
into the executable or library. The JVM isn't the fastest game in town
and just like any other programming environment, it can crash
unexpectedly and badly written code can leak memory and perform
terribly. Doesn't mean the JVM is badly designed - it's not - just
that it's built by humans and therefore imperfect.

The main advantages that a VM gives appears to be around O&M, tracing
and diagnostics. And the portability thing, but as GHC demonstrates
this can be done in other ways.