This book is an in-depth introduction to Erlang, a programming language ideal for any situation where concurrency, fault tolerance, and fast response is essential. Erlang is gaining widespread adoption with the advent of multi-core processors and their new scalable approach to concurrency. With this guide you'll learn how to write complex concurrent programs in Erlang, regardless of your programming background or experience. Written by leaders of the international Erlang community -- and based on their training material -- Erlang Programming focuses on the language's syntax and semantics, and explains pattern matching, proper lists, recursion, debugging, networking, and concurrency. This book helps you:.

Author:Torn Maukus
Language:English (Spanish)
Published (Last):24 December 2004
PDF File Size:20.23 Mb
ePub File Size:14.95 Mb
Price:Free* [*Free Regsitration Required]

He has used Erlang for 15 years, having started his career as an intern at Ericsson's computer science lab with the inventors of Erlang. He has written several books on functional programming an is co-author with Cesarini of Erlang Programming. The Erlang Factory is an event that focuses on Erlang - the computer language that was designed to support distributed, fault-tolerant, soft-realtime applications with requirements for high availability and high concurrency.

The main part of the Factory is the conference - a two-day collection of focused subject tracks with an enormous opportunity to meet the best minds in Erlang and network with experts in all its uses and applications. Can you please tell us a little bit about yourself and what you have been busy with lately? Francesco F : I am Francesco. I have been working with Erlang for about fifteen years as a software consultant, founder of Erlang Training and Consulting, with offices in London and just finished authoring a book "Erlang Programming" which is published by O'Reilly.

Simon S : I am Francesco's co-author so we have both just finished authoring the book. I am Simon Thompson from the University of Kent. I am an academic teacher and researcher; I have been working in functional programming for about twenty five years. With Haskell previously, more recently both with Haskell and Erlang. So you have just written a book about the Erlang programming.

What are your target readers? F: People who are new to Erlang people who want to learn Erlang and learn it in depth. From my side, when I started writing the book I was thinking of my students and lecturing in class, so the actual writing was based on a training material I just started lecturing and lecturing then typing away what you normally say in class, then you'd have a second round in complement with questions and focus on areas people thought were hard. S: But the people you are teaching are people who are experienced programmers who are learning Erlang for the first time.

And it was interesting for me, I have written books in the past for people beginning to program. So it's a different audience for me. So you can use to talk about people's experience and explain how Erlang is different than the languages that people are more familiar with. F: That's were it worked really well writing the book with Simon as a co-author because we merged these two views and aspects which gave the result we have got today.

S: And I think that for me it's the first time. I have written a few books in the past on my own. And I think it has been very interesting writing with a co-author. Because you think "Ok, it's going to be half the work" and that's not the case. I think it's the same amount of work but I think what you get at the end is of better quality because there are two sets of eyes who have seen it, you argued about the order of material and so on.

F: And you get very different views as well: you get the academic view and you get the industrial view, which really provides in my opinion the best mix and the best results. S: So the question is can you tell who wrote which chapter? I think that we hope you can't, we hope there's enough blend in that you can't immediately say "Oh Francesco obviously wrote that or Simon obviously wrote that".

Except for the Italian accent. F: What was happening is I'd write a chapter and Simon would write a chapter and then we'd send them to each other and we'd go through them again. And then I'd add jokes and send them to Simon, and Simon would remove them and then resend it back.

And so by the end, there was no single author to a a particular chapter, we just both worked with them together and contributed probably just as much. S: And I think what is interesting as well in writing a book like this, you learn stuff. I mean Francesco is very experienced in Erlang but I suspect he learned a number of things.

And I certainly learned. I knew about functional programming, I knew about the fundamentals of Erlang but I learnt a whole lot about how Erlang works with other languages, like Java and C, perhaps more that I have expected to, at the beginning of this enterprise. And also about Erlang and GUI programming, and so on.

So you learn a lot doing something like this. One of the sections of the book talks about design patterns, Erlang design patterns, which is more than simply using Erlang, right? Can you talk a bit about this section? F: It deals more with working with concurrency in Erlang, and reusing patterns from one process to another. And we split it up into two areas because first we covered design patterns with pure Erlang and it should be seen an introduction to a middleware called OTP which has libraries which encompasses design patterns.

And so by introducing these various patterns, it makes much easier and facilitates understanding of these libraries which are covered later on in the book. If you think of concurrency and Erlang the major design patterns you work with today, include client server, include supervisors, include event handlers and finite state machines which are the key ones we discuss. S: I think it's interesting the concurrency model in Erlang is based on message passing between processes that don't share any memory.

And that is a very nice model. But I think what makes Erlang really successful is not just the design of the language which has evolved and is very subtle and complicated thing, but it is this middleware layer that sits on top.

So it is possible to build a client-server system, for instance, without having to worry about the patterns of communication. There is a generic part, a generic server, that comes with OTP, so you can simply take that application and you write yourself the particular bit of behavior. Suppose that it's something that will check if something is an anagram or if two words are an anagram of each other; you just fire the words off, and write the little bit of program that would tell you whether one word is an anagram of another.

And you get built for you the whole client server infrastructure; it deals with failure and all these sorts of other things for free. F: When we are building distributed massively concurrent systems with requirements and high availability, the programming language in itself is not alone. You need middleware, you need built-in libraries, you need a way to structure your code and structure your system, and that is what OTP brings to Erlang, the programming language itself.

And I think all the practical large application you'll see will be Erlang plus this middleware layer. Another section of your book talks about functional programming. What about that? S: Well I guess that fits, it's a very nice basis on which to build a concurrent language. Functional languages think about the values how you calculate this result from these inputs, you are thinking at a higher declarative level, you think about relationships between values and not abut how to change one value into another through a series of assignments or whatever.

So it's a nicely abstract model and that fits tremendously well with this message passing concurrency. Erlang is a concurrent language and you can easily learn the functional programming parts of it. It's not difficult functional programming but it enables you to think about what is difficult and that is the concurrent or distributed part. F: I think I would like to quote Simon Peyton Jones here who said: "The concurrent languages of the future will be based on functional programming languages but we won't necessarily call them functional programming languages".

S: That is a nice insight, I like that. We do talk about the idioms that will be unfamiliar to people. So we talk about working in a language that doesn't have control structures, so instead of having loops that run forever which are inside a while construct, people learn about writing tail recursive programs so you have a function whose last statement in the body of the function is a call to that function again.

Perhaps with some slightly different data which effectively represents a state. But you are handling that state in a purely functional way, without having to do assignments to process that state. F: I think other interesting parts are programming in a side effect free environment where most of the functions are side effect free, and you try to minimize a number of side effects which in Erlang include IO, writing to databases, and message passing.

And that is another hurdle for people trying to understand and learn Erlang and really embrace it and use it properly to get over. S: But the message passing, if you are using OTPm if you are using the generic side of it, that is just handled in a functional way, you just say how this message should be processed, you don't have to worry about how it's received, how it's stored in the mailbox or whatever, that is abstracted away, you just use this generic model.

F: It's the pitfalls of concurrent programming: dead locks, race conditions, in a library so the programmer doesn't have to worry about it.

S: Cool stuff. Also you talk about type annotations inside the book. Can you tell us a bit about this section and type annotations? F: This was a very recent addition, a new tool which originally was developed by Upsala University which came out just recently with R13 release. S: What we are trying to do, Erlang in some senses is a bit like C, it is quite a small language it's a very liberal language, it doesn't have a strong type system like Haskell or ML, but what that means, it's a small language, it's relatively easy to write tools that work with it.

So Erlang comes with a whole lot of tools: for tracing, debugging, tools for refactoring and so on. But there are particularly a very nice set of tools that allow you to do type checking effectively; you can state the type that you think a function has, you can type check that, using a tool like Typo, so it's this very liberal language but the tool environment is very powerful, very strong, and that really helps with Erlang programming. Often you talked about software upgrade which is one very interesting feature of Erlang.

F: Software upgrade is something that you need to build into a language from the start it's not something you can add at a later date with some after effort and it was one of the very first features they looked at where how do you build non stop systems, you make sure you can upgrade the software during runtime. So using some very simple principles and constructs, you are able to change a pointer to the module where a specific process is executing maintaining the state, maintaining the values of the variables but just changing the actual code which is executing.

And using these very simple principles you are able to do software upgrades which give you systems with five nines availabilities including upgrades, and that is just a few seconds per year of down time. S: And just to stress, in other languages you would have to take the system down. F: Or find complicated workarounds where you've got primary you've got stand-by, you switch off to primary and upgrade it and then switch everything back.

You don't have to worry about this scenario like most of these cases are built in and handled with the capabilities and the tools that come with OTP. Not to say it's not simple, if you have backwards compatibility issues you need to upgrade the database schema and all backwards compatible protocols, it's still complex, but it's less complex than ordinary languages used for server side programming.

S: Just to make a general point about Erlang, one thing that is very nice about it, it's very focused, it was designed in the computer science research lab in Ericsson about twenty years ago and they wanted to find languages they could use to build things like telecom switches.

And they did an evaluation of all the languages that were around and found that none of them really worked. So there were just three people doing this work so it means that it's not like a language designed by committee. There is a small number of features, each feature has to justify its existence, you can see where code swapping comes from, you can see where distribution comes from, where passing comes from.

And the language has been remarkably stable it's not proliferated there is no bloat that you see perhaps in Fortran or languages like that where they changed beyond all recognition.

F: It's a language designed by prototyping, they were prototyping telephony applications and testing ideas and if an idea worked it made the code more compact, and easy to understand the capital feature. If it didn't help, they removed it. And prototyping which took several years before they started using it in commercial products. S: And I think one thing that's intriguing it was designed with, OTP stands for "open telecom platform", so there could be a worry that Erlang is just a language for doing telecom applications.

But in fact what you need to do telecom applications is precisely what you need to do for a whole lot of other things. So you see Erlang being used to handle systems where there is inherent massive concurrency, you are getting SMS messages coming at thousands per seconds. F: Instant messages, web services, any server side. S: And the point about that is that you then have a process per message, each message that comes in spawns a new process and you quite naturally get this huge amount of concurrency, which is very hard to do in something like Java.


Francesco Cesarini and Simon Thompson on “Erlang Programming”

Goodreads helps you keep track of books you want to read. Want to Read saving…. Want to Read Currently Reading Read. Other editions. Enlarge cover.


Erlang Programming

This book is an in-depth introduction to Erlang, a programming language ideal for any situation where concurrency, fault tolerance, and fast response is essential. Erlang is gaining widespread adoption with the advent of multi-core processors and their new scalable approach to concurrency. With this guide you'll learn how to write complex concurrent programs in Erlang, regardless of your programming background or experience. Written by leaders of the international Erlang community -- and based on their training material -- Erlang Programming focuses on the language's syntax and semantics, and explains pattern matching, proper lists, recursion, debugging, networking, and concurrency. This book helps you:.

Related Articles