Forgot your password?
typodupeerror
Book Reviews Books Media

Programming Erlang 314

Posted by samzenpus
from the read-all-about-it dept.
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.
This discussion has been archived. No new comments can be posted.

Programming Erlang

Comments Filter:
  • Try it out (Score:5, Informative)

    by romiz (757548) on Wednesday September 05, 2007 @02:51PM (#20483307)
    The first chapter [pragmaticprogrammer.com] is avalable online to get a taste of the book (and the language).
    • by Jhan (542783)
      The Ericsson Language, for those who have not been exposed to it, is a programming language meant to make concurrent (multi-process, multi-processor, multi-machine) programming really simple. It's used on many AXE telephone base stations world-wide. It has great message-passing support, and a pretty nice library. It is actually not a functional language, but a logical one. Basically a perverted version of Prolog.
      • by MenTaLguY (5483)
        Erlang is a functional language with prolog-style unification for pattern matching, just like one sees in ML or Haskell.
      • Re: (Score:3, Insightful)

        by nuzak (959558)
        Erlang does not stand for "Ericsson Language". It's named for the the telecom term, which itself was named for A. K. Erlang.

        And yeah it's like Prolog, except without horn clauses or backtracking. You know, just like lisp and java.
        • Re: (Score:3, Interesting)

          by lastninja (237588)
          Actually it stands for both.
        • Re: (Score:3, Informative)

          by Hal_Porter (817932)
          Ericsson is a Swedish company, founded by Lars Magnus Ericsson [wikipedia.org]. Erlang was developed by Swedes at Ericsson but is named after Erlang who was unfortunately Danish. It is possible some Danes sneaked in and did this naming before the security guards could throw them out.
  • by DoofusOfDeath (636671) on Wednesday September 05, 2007 @02:56PM (#20483403)
    I bought the book while it was still being written. I was able to download drafts, and (if I had the time) submit bug reports. When it was finally done, I got a printed copy in the mail.

    I haven't had much time to play with Erlang (or the book) yet, but it was a really nice feeling to be able to get early access as long as I was willing to see unpolished content. Bravo, publisher.
  • by SanityInAnarchy (655584) <ninja@slaphack.com> on Wednesday September 05, 2007 @02:58PM (#20483437) Journal
    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: (Score:3, Informative)

      by DaveTerrell (923)
      You can do reload natively compiled modules. In fact, you can replace a native compiled module with a byte-code one and then vice versa, in a running vm. I just did it 5 seconds ago.

      You can use periods and @s (and anything else) to namespace atoms, if you want. The module loader will even track down module foo.bar to foo/bar.beam... compiler support for it isn't great but it works. nobody bothers to use it though.

      The syntax takes a while to get used to, but it becomes very easy to write.

      What I've found
  • by ikewillis (586793) on Wednesday September 05, 2007 @03:02PM (#20483511) Homepage
    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 (Score:4, Informative)

    by UglyMike (639031) on Wednesday September 05, 2007 @03:04PM (#20483535)
    Strange that I didn't see Wings3D mentioned yet. ( http://www.wings3d.com/ [wings3d.com] )
    It's an open-source subdivision surface modeler held to great esteem in the modeling scene

    It is also an Erlang application....
    • Re: (Score:3, Interesting)

      by TheRaven64 (641858)
      What about eJabberd? It's currently the most feature-complete open source Jabber server, and it's written in Erlang. I've just migrated from Jabberd (written in C, and older) to eJabberd for the features.
  • by Z00L00K (682162) on Wednesday September 05, 2007 @03:06PM (#20483573) Homepage
    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 [sourceforge.net].

    • by Jugalator (259273)

      it's well worth to mention that a large number of telecommunication devices from Ericsson are running software written in Erlang
      Something more interesting to me would be use outside of Ericsson. Erlang is after all short of Ericsson Language, so what you say is not surprising. However, does this imply it's wide spread in e.g. telecommunications outside of Ericsson? Any other common, modern, use besides for the occasional pet project?
  • by homer_s (799572)
    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.

  • Overall, the book is very good: the examples are clear and useful, and for an old Prolog programmer like me, Erlang has a natural feel to it.

    I have been disappointed that none of my customers seem to be interested in Erlang development - I proposed using it for one application where 'share nothing' asynchronous communication seemed like a very good fit.
  • 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.

    Would a good analogy be that an Erlang process is comparable to an object instance, in that both are loosely coupled (ideally), focused on one task (ideally), but in Erlang they're all running asynchronously and the OS/runtime automatically handl

    • by MenTaLguY (5483)
      Yes, that's a reasonably good way to think of them, with the proviso that an Erlang process doesn't bind particular code to the receipt of particular messages like you see in OOP (where particular bodies are bound to particular methods). When an Erlang process receives a message, it's up to the process to decide what to do with it.
  • A great book on Erlang, but missing a few details on the usage of common libraries. In particular it could do with more information on how to drive the Mnesia database. I started programming Erlang a month ago and the shortage of implementation docs on the database and list libraries has been a problem for me.

    Yes, I do know about the Ericsson Mnesia manual and http://trapexit.org/ [trapexit.org]

    Vik :v)
  • It's worth noting that ejabberd [jabber.ru] is written in Erlang.

    For those who haven't heard about it, it's an open source, distributed, fault-tolerant instant messaging server (Jabber/XMPP), modular and very configurable and is readily available in most Linux distributions' repositories.

    It's one of the most promiment erlang-based projects.

  • It's worth looking at

    http://shootout.alioth.debian.org/gp4/benchmark.ph p?test=all&lang=hipe&lang2=hipe [debian.org]

    for the general performance of erlang. It compares unfavorably in those tests to lisp and clean, two other functional programming languages.
  • As somebody writing code in Erlang as a profession, I say, though it has strength, it's crap. It has strength in the efficient handling of many processes (faster then the OS when there are many many thousands of them), aand (re)loading modules on the fly into the virtualmachine is nice. But on the flipside Erlang is slow as it's a very high level language, with a not so clever virtual machine - much less so than java vms (well I have to admit I am an assembly&C fan). Also functional programming my ass.
  • to give you an example of something built in Erlang take a look at http://www.couchdb.com/ [couchdb.com] CouchDB is an Open Source (GPL) database back end. It is in some ways inspired by the database architecture of Lotus Notes, it is a non-relational document based store with strong replication ability. Don't bother bitching about Notes, the new UI is quite different to the old look (personally I liked the old style) but CouchDB doesn't have a UI, it has similarities at the architecture level which is where Notes is ve
  • classic papers (Score:2, Informative)

    by rsilverman (266807)
    Here is a classic paper on the style and advantages of functional programming:

    http://www.math.chalmers.se/~rjmh/Papers/whyfp.htm l [chalmers.se]

    Also, John Backus' Turing Aware lecture, "Can Programming Be Liberated from the Von Neumann Style?"

    http://www.stanford.edu/class/cs242/readings/backu s.pdf [stanford.edu]
  • An article on functional programming is the perfect time to introduce my new son, Nick, to Slashdot. Previous releases were in C [slashdot.org], Perl, and Python [python.org]. Since Nick's functional, this one [honeypot.net] is in Lisp.

    Mod me up or my son will spit up on you.

  • IAAEP (Score:4, Insightful)

    by schmiddy (599730) on Wednesday September 05, 2007 @10:23PM (#20489239) Homepage Journal

    I am (well, was, at least) an Erlang Programmer. I was toying around with Erlang for some small projects [sf.net] with distributed programming.

    I've been looking forward to Joe's book for a long time, as he's one of the few big names in the Erlang community, and has done a lot of work (both code and, even more importantly, documentation) for the community -- first that jumps to mind is his important look at Yaws vs. apache [www.sics.se].

    There are serious problems with the Erlang language as a whole and the community, right now. The mailing lists are actually pretty good, but quite frankly, the documentation online is terrible and the Erlang interpreter is pretty rudimentary. Not to mention basic problems with the syntax and grammar of the Erlang language itself. When I was learning Erlang a few months back, I was pretty frustrated that about the only source of documentation was on erlang.org [erlang.org], and they.. weren't great. For instance, there needs to be a big warning right at the beginning explaining that atomic values always start with a lowercase letter and all other variables must begin with a capital letter. This must be a huge problem for other beginners (at least, I hope I assume I wasn't alone..) compounded by the unfriendliness of the error messages produced by the Erlang interpreter.

    Now that I've switched over to doing as much as I can in Python, which has a great user community, wonderful docs, a healthy standard library, and a reasonably helpful interpreter.. I don't really worry about Erlang that much anymore. It would be wonderful if I could write, say, web crawlers (I work in web security) in Erlang. But the mysql support in Erlang looks alpha-quality at best, and AFAIK there's nothing even remotely similar to Python's urllib2 for basic web client functionality in Erlang.

    I think it says a lot that so much attention is paid to a language that is so rough around the edges, unfriendly, and lacking in documentation. Even given all that.. the ease of use of the concurrency and message passing in Erlang is so fantastic that it almost makes up for the rough spots.

    On a final note, I'd like to point out to anyone interested that I think there's a huge void out there for a language that's as easy to use and learn as Python, but with the concurrency and message passing in Erlang. It actually might not take that much work to build a network-transparent message passing interface as a Python module (I've looked into Pyro [sourceforge.net] a bit.. it looks rather cumbersome and makes easy things too hard, correct me if I'm wrong). Also, modern languages need basic support for splitting up the workloads of map() or similar trivially parallelizable functions across multiple processors/cores (I know the Perl6 group was thinking about this.. not sure if this works in Parrot now or what). Basically, modern languages like Python/Perl/Ruby should really think more about making simple modules to mimic the message passing that Erlang has. Really, a little bit of code could go a long way. The Google team put together sawzall [google.com] which looks kind of cool, on this note..

Real Users never know what they want, but they always know when your program doesn't deliver it.

Working...