[erlang-questions] Forget Erlang on the Java VM. More language on the Erlang VM are needed!

Bob Ippolito bob@REDACTED
Wed Nov 28 19:00:36 CET 2007

On 11/28/07, Michael Regen <michael.regen@REDACTED> wrote:
> On Nov 28, 2007 4:04 PM, Joel Reymont <joelr1@REDACTED> wrote:
> > I may be wrong here but the advantages of using Java over Erlang for
> > the CIO lie not so much in the technical merits of Java as in the deep
> > pool of Java developers.
> On Nov 28, 2007 4:11 PM, Sean Hinde <sean.hinde@REDACTED> wrote:
> > My experience has shown that if you want to persuade a CIO of this
> > mindset to use a new fancy programming language, then the choice of VM
> > is a detail of miniscule importance.
> > Arguments are much more about support, availability of programming
> > resource (including option to outsource if the in house team proves
> > too troublesome or expensive) etc etc.
> I was silently referring to outsourced or ready to buy solutions. Where CIO
> dream about: No in-house development but outsourcing and buying solutions.
> And technologies like SOA, etc. give you interoperability.
> I was approaching the topic rather from the external integrator's view - not
> from the internal perspective. And then the pool of developers, support,
> etc. is your problem regardless of your solution's programming language.
> Your customer's CIO wants a solution which works, is cheap, future proof,
> reliable and fits into the company's strategic and environment. Not
> necessarily in this order.
> Under this scenario the least they want to do is to touch your solution's
> code. Which makes the underlying programming language not _that_ important.
> More important are of course your qualities as an integrator/solution
> provider (many different aspects) and: Does this solution fit into my
> environment? Is this VM really stable? Who is Ericsson? (SCNR) Can we trust
> the solution's stability given that not many other companies have any
> experince with it and my CIO magazine never mentioned a product based on the
> whole concept? Is it based on technologies we already use or do I have to
> send all our admins to courses? Etc, etc.
> If we can say, our solution is based on Erlang but it runs in your well
> known and proven Java environment, you can much easier give answers to their
> questions. BTW: this is also true if you see it from the internal viewpoint.

If someone were to release Erlang for the JVM or CLR tomorrow I
probably wouldn't want to go near it for at least a year or three even
if it was faster or if I had a use for the additional in-process

One of the biggest reasons that I decided to standardize on Erlang as
one of the accepted languages for my company is that it actually works
*today*, and I don't really have to worry about the implementation
because it has an excellent track record. We've found a few warts in
the past year, but nothing that caused us more than temporary
problems. For the most part we've ended up with applications that work
as they're supposed to and we've been able to build them on or ahead
of schedule and we don't have to take things down when we want to fix

I really don't see the point of discussing Erlang on other VMs unless
someone actually builds one worth talking about. How about you guys
start another mailing list for talking about alternative Erlang
implementations? I'd rather not have to read about it here.


More information about the erlang-questions mailing list