Is Erlang the Java for the concurrent future?

Hi Niclas,

There must be some alignment of the universe at work here :). I am currently looking into Erlang for my current engagement which lives in the space of producing official statistics for countries. The volume of data to be processed, real-time ETL requirements, and the proverbial concurrency issues led me to Erlang. The side effect for me was that tackling my problems from a functional perspective (as opposed to an OO perspective) may well yield a cleaner service model than what I originally conceived. Time will tell.

I also have to work with metadata that must be semantically correct and semantically interoperable (within the organisation and outside it as well). There's the case for Erlang being cleaner and easier to walk massive directed graphs (think OWL, RDF, etc) than, say, Java. For me the question is "Is Erlang the language for Web 3.0".

Regardless, Erlang should be learnt. Our obsession with object orientated analysis needs a timeout, and functional analysis is a good alternative. IMHO, Erlang is definitely easier to digest than Haskell.

Erlang's a very interesting language, and people should definitely do more with it. However, Scala is a next-generation JVM based language (think Groovy done right) and also encapsulates the concurrent message-passing actor pattern from Erlang, which makes it possible to use it in and with Java.

lamp.epfl.ch/~phaller/doc/ActorsTutorial.html

Hello Aslam,

It must be synchronicity.

I agree with you. Even though I'm a strong OO-advocate in many cases, there are definitely a lot of problems that just doesn't fit an object model very well. Us as an industry needs to expand our horizons to different ways of thinking more often than we do. We need to take the time; there is a lot of time to save by choosing the right tool for each job.

Alex: Interesting link. Scala is on my radar, but this looks like a good starting point for playing around with it -- thanks.

One of the problems I have with Erlang at the moment is its dependence on the GNU toolchain, i.e. you cannot build it from source without gcc/gmake. If Erlang is going to reach a wider audience it needs to eliminate the dependence on GNU specific extensions so that people can build it from source using, say, the Sun or Microsoft compilers.

>I agree with you. Even though I'm a strong OO-advocate in many cases,
> there are definitely a lot of problems that just doesn't fit an object
> model very well.

www.kirit.com/Blog:/2007-08-09/Erlang%20as%20an...

Since OO is about sending messages, I'd say Erlang has the best of both functional and OO worlds. Just because there's now dot syntax (foo.bar() for method invocation) doesn't mean OO concepts can't be applied.

Since OO is about sending messages, I'd say Erlang has the best of both functional and OO worlds. Just because there's now dot syntax (foo.bar() for method invocation) doesn't mean OO concepts can't be applied.

For single-CPUed parallel nodes, "share-nothing" is natural and most efficient, but why not "share something" when it comes natural and easy for CPUs/Cores in a same space? That should give Java more power than Erlang IMHO.

i share your surprise. message-passing is far from a new paradigm in parallel software development and the truth is that although it is clean and secure (if you discount the danger of deadlocks) it is far from convenient. being able to share memory/objects/state - which is what every multi-CPU or multi-core architecture gives you naturally - between concurrent threads is actually a major relieve over the stringency of having to communicate by messages only. in that sense i place more hope in the java.util.current features introduced in java 5 and to be enhanced further in java 7.

cheers,
gerald

www.gerald-loeffler.net

pardon my typo: that was meant to be "java.util.concurrent", of course...

@Compl Yue Still

Well - in *general* - as you scale to very large (>5,000) numbers of processes, in most applications the ratio of (a) communications between a small number of processes (say: 1 sender to 10 receivers) and (b) communications in a large group (say: 1,000 receivers) will become asymptotically close to one. Therefore implementations that explicitly share nothing will outperform those where messaging is implemented on top of shared memory.

And, if you do not know where the processes are distributed (across one CPU, or many cores, or over a network) then it is not obvious where to optimise for latency vs throughput, in a shared memory implementation. This further favours message passing approaches in being generally easier to apply successfully, and manageably if the system changes. You could call this property 'scale invariance'.

Finally, in a process centric language, shared memory is (logically) just a process. That is one way to implement a form of shared memory in Erlang.

@All

Personally I do not like these 'my language is bigger than your language' discussions. A good way to use messaging in Java/C# etc is to provide it as a low level service in the VM - like how people use remoting, it's a data communication layer. This could also work for Scala to deliver 'remote actors'.

We've found Erlang to be a good fit for implementing RabbitMQ which delivers messaging to Java and other languages, using the open 'AMQP' model for communication. This is not just for the reasons mentioned in the InfoQ article (good for concurrency and multicore) but also (1) because it is inherently extremely distributable without paying heavy performance costs and (2) it is very expressive so code complexity costs are lower e.g. the RabbitMQ codebase is *very* small.

Cheers

alexis

@Gerald

In fairness (no pun intended) this is less true in Erlang in which using messages is incredibly natural. For OO languages it may be more natural to use an object facade for messaging - clearly there are lots of ways to do this, and some of them look like shared memory.

@All

I recommend that people follow up on the Ralph Johnson article for more details. Another place to pick things up is on this forum.

I wrote objectoriented code in C for a couple of years in the beginning of the 90's, so no objection there.

A long time ago, I did something like this using function pointers as entries in a table linked to from structs and invoked via macros.

Don't ask for details, it still makes my nose bleed to think about it.

Recent events with Skype suggest that people might indeed care ;-)

It's been said that a Fortran programmer can program Fortran in any language. I wonder whether the same applies to Erlang :-). It certainly seems to be getting a lot of attention from the OO community recently. The keynote talk at ECOOP this year was about Erlang, which is certainly a first!

We'll be having a talk from Joe Armstrong, the creator of Erlang at JAOO in Aarhus, Denmark this year. It's not too late to get the early registers discount if you want to come and tell him why Erlang is (or isn't) OO. We have Lex Spoon from the Scala group too, for comparison purposes :-).

I'm not sure Erlang is OO myself, but hey, just because we have those two letters in our conference name, doesn't mean we can't get some inspiration from other paradigms.

--
Aino Corry, Trifork
Program committee member, JAOO & QCon

@Aino

There is some discussion of your question regarding Erlang and the OO metaphor here

The author's conclusion is that "I have to agree with Ralph, Erlang is an object oriented language, but one where the objects themselves are implemented in a functional language".

Whether you agree with the author or not, it's also true that it would be tricky to 'program Erlang in any language' for lots of reasons, such as that every process has its own heap so that you can have *millions* of processes. It would be more accurate to say 'you can program the actor model in any language', but even that claim is a highly underdetermined :-)

@Dean

Just like Stefan said, you have to "roll your own" by making tricks with functions pointers.

For single-CPUed parallel nodes, "share-nothing" is natural and most efficient, but why not "share something" when it comes natural and easy for CPUs/Cores in a same space? That should give Java more power than Erlang IMHO.

How does Erlang compare to Haskell? There seems to be more books published about Haskell. Does that mean that it is more mature and widely used? If one was going to invest the time and learn a functional language, which would be the better one?

So many languages and so little time...

I did the same in PL/1 on IBM mainframe at roughly the same time...
Likewise, it was fun at the time but I do not care to remember the details (;-)