Developers moving to Erlang for code scaling

Quoted from an interesting article at SDTimes article titled ‘Developers moving to Erlang for code scaling’.

Katz came to [Erlang] for its concurrency, which allows for cheaper scalability, he said. He had worked with threads and locks in C++ for many years prior to learning Erlang in 2007. “Instead of having these threads which live in the same process and can see the same global data, Erlang has what’re called processes. There are little virtual processes, and they all live inside the Erlang virtual machine,” said Katz.

“They can’t see each other. All they can do is send messages. They can send asynchronous messages, and that’s how you do all of your concurrency. Instead of global data, where you modify it and read it and set a global lock, you send it a message and say, ‘Give me a value for foo,’ or you might send a message like, ‘Increment the bar value.’ You have these processes, and they are self-contained, they have their own memory, and they can die. It’s a very different programming model than the traditional threads model.”

Erlang seems to be very much in the spotlight nowadays and gaining, albeit slowly, in mainstream popularity. At a time when multi-core utilisation and easier, more intuitive and more scalable concurrent programming models are of prime concern it certainly looks very promising indeed. The alternatives such as Scala actors and Guild Actors Framework aren’t as compelling in my opinion. My inexplicable gut feeling is that we need a language, a programming paradigm and an interpreter that are radically different in order to exhibit characteristics and give results that are radically different and in order to do that we need to break free of the JVM. Erlang doesn’t operate within the bounds of the JVM; it interfaces with the operating system directly and by virtue of having its own interpreter, reassuringly, isn’t yet another layer of abstraction over JVM byte code either. For ultimate fault tolerance, concurrency and scalability it stands on its own feet (completely free of Java) and has already proved itself in the realms of telephone switching networks. Not only that but RabbitMQ – one of the first broker implementations of AMQP (the emerging standard for high performance messaging) is written in Erlang by choice with full justifications provided.

Ultimately, to generalise on the goal, as computer scientists love to generalise and project the common factor, the essence of the overall progression is in reducing contention whatever kind of contention that might be whether for hardware resources, shared data or software latency. This is evident in almost everything that we are doing nowadays – whether this is allocating more objects on the heap instead of using synchronisation, relying more on asynchronous processing of long running tasks, creating more push and not poll transmission protocol frameworks and relying more and more on high performance messaging, grids and clouds and advancing our imperative concurrency models (as with Java 7) – the end result or goal is modularising our infrastructures, reducing coupling between interacting modules and reducing contention for those modules and the data they process. How we can achieve this most effectively is the problem we are trying to solve whether it is through compiler optimisation and parallelisation (static or otherwise), improving existing programming models, adoption of functional programming languages or with multi-paradigm programming languages like Erlang. It will be interesting to watch how Java and .NET evolve in response to growing interest in other radically different technologies such as Erlang. Yet another framework or API abstraction is not going to cut it this time.

Leave a Reply