Programming Erlang

gnalre writes "Every day it seems there is a new publication of a book on perl/python/ruby. Some languages however do not seem to get that sort of attention. One of those under-represented languages is Erlang, however for the first time in 10 years a new Erlang book has been published. As someone who had a brief flirtation with Erlang long ago, I was interested to see how the language had evolved in the intervening decade. I was also curious to re-evaluate Erlang to see what solutions it offered to the present day issues of writing reliable distributed applications." Read on for the rest of Tony's review. Programming Erlang - Software For A Concurrent World author Joe Armstrong pages 515 publisher The Pragmatic Programmers rating 8/10 reviewer Tony Pedley ISBN 1-9343560-0-X summary Parallel programming the easy way

Programming Erlang — Software For A Concurrent World (ISBN 10193435600X) is part of the pragmatic programmer series. As with all the books in this series, it is available in paperback or for a reduced cost you can directly download it in PDF format (which is always useful if you spend a lot of time on the move and you do not like carrying around a dead tree with you). The book's format and layout as with all the books of this series are clear and logical.

The book is written by Joe Armstrong, who co-authored the first Erlang book a decade ago. He was also one of the originators of the Erlang language and has been directly connected to its development ever since. We can therefore be assured about the author's knowledge and insight into the language, if not his impartiality.

The book itself can be roughly split into three main sections: Getting started and Sequential programming, Concurrent Programming and Erlang libraries and advanced Erlang techniques.

In Chapter 1 the author sets out his stall of why Erlang is worthy of your attention. It's clear from this chapter that the author feels Erlang's strength lies in applications requiring an element concurrency and fault tolerance. Another emphasis is made of running Erlang on modern multi-core processors, something that was only a glint in a hardware designer's eye 10 years ago, but is rapidly becoming an issue in all areas of programming. From this chapter you also get a feel on how the author approaches his programming in that he states that he wants the reader to have fun with the language, which is a refreshing change to some language text books whose main purpose appears to be as a cure for insomnia.

Chapter 2 goes through installing Erlang and the Erlang shell (a command line environment similar to ones with languages such as perl). The chapter also starts us into the strange world of functional programming, where variables can only be given a value once (e.g you cannot do i=i+1), recursion replace loops and pattern matching replaces assignments. Fortunately the Erlang language is remarkably concise. For example there are only 4 data types. However to those coming from a purely procedural programming background the learning curve could be a steep one. Saying that the Author does a good job of leading you through the languages intricacies with examples being compared to code from languages such as Java to help keep your feet on solid programming ground.

The next 3 chapters move on to writing simple Erlang programs. As a quick aside, for anyone new to Erlang it is well worth examining the quicksort implementation described in chapter 3. Its conciseness and simplicity was one of the reasons the language won me over when I first met the language.

These chapters also cover error detection and handling. It's worth noting that Erlang has a philosophy of ensuring programs fail hard, so that bugs can be weeded out at an early stage. This idea very much defines how Erlang error handling is defined.

One criticism of the first section is Chapter 6, which describes compiling and running an Erlang program. I would have preferred that this information be covered earlier in the book or be placed in an appendix because it is probably an area you will want to reference repeatedly.

Chapter 7 is where things really get interesting and the true power of Erlang starts to come to the fore. This is where Erlang's concurrency credentials are explained. This chapter begins by providing some useful metaphors of the Erlang concurrent model, but chapter 8 is where the fun begins by describing the Erlang concurrency primitives that allow the creation of processes and the process communication methods. The author here highlights one of the language features, the Erlang light weight process. These are true processes (not threads) but take up very little in the way of resources. Indeed it is not unusual to have 1000's of such processes running in an application.

The next few chapters expand on the available concurrency primitives and how to move from concurrency on your local processor to concurrency utilizing the resources of multiple machines either on a local network or across the web. It finishes the section off by showing the example of a simple IRC application.

Chapter 12 starts the next section by looking at how to interact with the world outside the Erlang environment. First it examines how to interface an Erlang program to applications written in other languages such as C. It then goes onto to look at file and socket handling in Erlang. Chapter 15 looks at two important Erlang storage primitives ETS and DETS before we get to the OTP Erlang libraries in Chapter 16.

The OTP libraries are the standard Erlang libraries and tools. In fact the OTP libraries are worthy of a book in itself. The author highlights the section on the generic Server module as the most important section in the whole book and one to be reread until its importance has sunk in. This is because here are encapsulated many of the lessons learned in writing industrial fault-tolerant applications, such the updating of a running applications code without causing that application to miss a beat. The section is finished off by describing the Erlang distributed database (humorously named Mnesia) and then finishing it off with the example of a simple server application.

The book finishes off by looking at Erlang on multicore systems including its support for SMP. As the author states this is the leading edge of present day Erlang and is still under development.

I would like to thank the pragmatic programmers for publishing this book. Erlang's profile has been in need of highlighting for many years and hopefully this book will help. The book definitely provides a great starting point for anyone who wants to get to grips with the language and takes them to the point where they can start writing useful applications. This book is a worthy successor to the last book published and does a good job of both updating the material and explaining some of the later developments such as SMP. Anyone who has a need for writing fault tolerant applications should at least look at this book. If nothing else you will never be afraid of dealing with recursion ever again.

In many ways the book cuts off just when things are getting interesting. There are hints in the book about real world Erlang's applications and it would have been good if some of these experiences could have been expanded. Hopefully this book is the start of increased exposure for Erlang. If so then someone may get around to writing another Erlang book describing some of the advanced issues about generating robust applications. I just hope it won't take another 10 years this time.

Tony Pedley is a senior engineer specializing in real-time embedded systems. In his spare time he likes to tease windows programmers and confuse managers by telling them it would be a lot easier if we wrote it in Erlang.

You can purchase Programming Erlang - Software For A Concurrent World from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Try it out

[romiz]

The first chapter is avalable online to get a taste of the book (and the language).

Re:Try it out

[Brummund]

Authors should give away their books, and instead earn their money giving seminars and lectures.

And, as I'm told, earn top dollar from merchandise like t-shirts, mouse pads and coffee mugs.

What's missing from Erlang...

[SanityInAnarchy]

Last I checked, there was an implementation issue and a design issue.

The design issue, for me, was a lack of namespaces. I think it might have been that I can't have an atom with a namespace, beyond prefixing, which is a hack for languages that don't support namespaces.

The implementation issue was that you had to choose between performance and being able to reload functions later. I would very much like it to be able to JIT or even compile down to binary (x86_64 too, pretty please?), then be able to just leave it running, and have it reload functions as needed.

I'll have to think of what else I didn't like, but I don't think there was much, aside from some odd syntax. I don't actually have a problem with the somewhat functional nature of it, just certain syntax that looks ugly, but that's a matter of opinion, and something I can live with.

Re:What's missing from Erlang...

[be-fan]

But that's what I'm holding out for, is a high-level language with good performance that at least approaches C.

There's basically a handful of languages that would meet your needs here. On the dynamic side, you've got Common Lisp. On the static side, you've got ML, O'Caml, or Haskell.

After that, your options trail-off significantly. The other dynamic languages are all much slower than Lisp (more in the league of Python than in the league of C), and the other static languages (C#, Java), are much lower-level/less productive.

Possibly the greatest programming book I've read

[ikewillis]

This book is written by the language's creator, Joe Armstrong, and provides one of the best introductions to a programming language I've ever seen. The entire approach is nicely bottom up, with the idiosyncrasies of the syntax presented immediately so they are not confusing later. More powerful features are introduced, such as the tools for concurrent and distributed programming, with the book finishing off with the immensely powerful Open Telcom Platform and its associated tools, such as the "one server to rule them all" gen_server implementation and Erlang's distributed database, Mnesia.

All in all this is an excellent book about an excellent language and I would highly recommend it to any programmer, especially those concerned with the multicore future which will increasingly demand concurrent programming languages.

Wings3D

[UglyMike]

Strange that I didn't see Wings3D mentioned yet. ( http://www.wings3d.com/ )
It's an open-source subdivision surface modeler held to great esteem in the modeling scene

It is also an Erlang application....

Review worth a +1 karma!

[Z00L00K]

The review is well written, and even though Erlang is a programming language that not everyone is used to program in it's well worth to mention that a large number of telecommunication devices from Ericsson are running software written in Erlang, so most people has probably been using it without knowing it.

And in my opinion; If you are familiar with more common languages like C and Java you should take a deeper look into Erlang unless you prefer to study Prolog or Cobol. Just take a dip or a deep plunge, you never know when you end up in a project where knowing Erlang may prove useful - it is actually developed to be used in real applications and not as a theoretical study object.

And Erlang is designed to handle concurrent programming from the bottom, which is a real problem in large multi-user systems. You can of course use C or Java and solve concurrency problems with semaphores or synchronization, but the solution in Erlang may be much more elegant.

And for all of you that are familiar with the Eclipse development environment; There is a plugin called Erlide.

Re:The Seven Deadly Sins of Erlang

[Anonymous Coward]

Lets look at these "sins":
1. Not a sin, not needed and shows you don't know what you're talking about wrt reliability. hard real time is irrelevant.
2. More FUD based on your lack of understanding of programming.
3. is a downright lie
4. Contradicts three!
5. Ok, now I'm thinking you're not just a troll but verifiably insane. Show us a language (one that exists outside your head) thats not "alkorithmic"
6. Contradicts itself- is it based on english or is it cryptic?
7. Asinine in the extreme, and of course contradicted by the other 6 points. erlang is not logo

Bottom line- you are just making assertions that make no sense. If you ever were a programmer, you never learned much about programming... and your constant bashing of erlang is just an attempt to get attention. COSA doesn't exist, except in your head, where it can be magical and change as is needed for you to make whatever "point" you want to make.

I guess its a sign that erlang is becomming mainstream that it has attracted a loon such as yourself.

Re:The Seven Deadly Sins of Erlang

[Wesley Felter]

Summary: "Erlang isn't based on my fringe pet theory, so it sucks".

Re:The Seven Deadly Sins of Erlang

[jguthrie]

I often judge the quality of something by looking at the quality of the criticisms of it. If that's the best criticism of Erlang that you can find (or come up with) then Erlang looks pretty damn good. Of course, if you could see your way clear to describing how to write programs without implementing algorithms instead of simply explaining in great detail that algorithmic software is bad, maybe I would find it easier to embrace your view of programming.

Re:I know why it's been 10 years

[J.R. Random]

There is nothing in the second example that isn't completely familiar to anyone who has ever programmed in LISP, one the world's oldest programming languages.

Newbies, feh!

Re:The Seven Deadly Sins of Erlang

[rk]

See, here's the thing: I can download Erlang and start to learn it right now. Where can I find COSA? That's right, it's vaporware.

Who knows, you may be on to something. I'd suggest writing fewer white papers and less name-calling of your detractors and get busy implementing your vision. Nothing will shut them up faster when you've got something that lets people develop systems that are more reliable for no extra cost.

Until then, you're in the same category as people who promise us perpetual motion machines and anti-gravity levitation.

Have you ever written a loop?

[Estanislao Mart�nez]

It's very different, but the big advantage is that it's higher level than the stuff you confess to understanding better.

The code in question (in Python? not a great choice for doing an example!) uses two very common higher-order operations in functional programming: map and compose. A map operation takes a complex data structure (most common example: a list), and a function that applies to elements of that data structure, and returns another structure, with the same "shape," where each element in the result is related to its corresponding element in the original structure by being the result of apply the function. Thus, if you have a list [2, 3, 5, 7], and a function inc that increments a number by one, map(inc, [2, 3, 5, 7]) evaluates to [3, 4, 6, 8].

In the case of a list, map is can be implemented by creating a new list of the same length as the original, looping over the list, applying the function to each value, and storing the result in the result list. This is a kind of task that imperative programmers find themselves doing all the time. The problem with this, however, is that if you're writing code like this all the time, you're writing at a much too low level, with the all the disadvantages of that:

1. It takes you longer to write code. Instead of writing just result = map(fn, myList), you have to write a loop.
2. Your code is specifying the mechanism to convert the input list into the output list over and over, instead of describing the relation between the lists. Suppose you want to change the mechanism for doing this sort of operation, e.g., to parallelize it. In functional style, you can just rewrite map to do its work in parallel. In imperative programming, you have to work harder.
3. The concept of mapping a function over a structure, to produce a new structure with values related to the original by the function, applies to many kinds of data structure, not just sequences. You can write equivalents of maps for any container data function you like, even though the mechanics are different; e.g., to implement a map function over a tree you typically use recursion. This means that in the imperative style, the code for "increment all the values of this list by 1" looks very different from the code for "increment all values in this tree by 1"; in functional programming, they will at least look very similar, if not completely the same.
4. There are many, many other common progamming blocks that you can abstract into a function in functional programming, but not in imperative programming. For example, filtering a list to only keep the elements that satisfy a boolean function, which in functional programming is usually just a function called something like filter. For example, if you have a function called even, that returns true only for even numbers, here's how you get the even numbers in myList: filter(even, myList)
5. Functional programming solutions often compose more easily than imperative ones; i.e., it is easier to put them together to solve more complex tasks. For example, if you need to increment a list of numbers by one each, and only keep the ones that are even in the result, you can do that easily and transparently: filter(even, map(inc, myList)). In the imperative style, the patterns for mapping and for filtering don't combine this straightforwardly.
6. Functional code is usually easier to read. When I read a piece of imperative code and come across a loop, I normally have to work the steps a bit in my mind in order to see what it is that it does: "Hmm, we create a new list at the beginning, then we loop through the elements of this other list, and as we go through each one, we apply a function to it, and put the result in the list we first created. Ah, we're mapping over the list." In functional programming, these common patterns find immediate expression in a higher-order function

Re:I know why it's been 10 years

[be-fan]

Also next to impossible to maintain, debug, or understand.

Uh, if you don't know functional programming, then yeah. If you do, it's instant to understand, and can be maintained more easily because there is less of it to maintain.

Your argument basically amounts to "stuff I don't know is hard to understand". No shit. New notation and concepts have to be learned, yes, but there is a point to learning them. It makes things simpler and easier once you have learned them. Consider, why do people in signal processing do all sorts of Z transforms and Fourier transforms and whatnot on data? Surely it's _easier_ to just think of a sound signal as a series of amplitudes at discrete time intervals? The thing is --- it isn't. Once you learn all that math, you can do stuff with signals by hand that you couldn't even have dreamed off if you'd used a less powerful technique.