Erlang and OTP in Action 63
RickJWagner writes "Manning has just released a new Erlang title, called Erlang and OTP in Action. For quite some time now, there's been a definitive guide to Erlang-- Joe Armstrong's excellent book Programming Erlang. Well, it's time to make a little extra room on the bookshelf, because the Erlang book-o-sphere has just shifted. There are now two must-have resources for an Erlang programmer." Keep reading for the rest of Rick's review.
The book is divided into three sections. The first one deals with the basics of Erlang and details about the OTP application framework. Part two shows how to build a production-worthy application in Erlang. The third part of the book is about integration and tuning.| Erlang and OTP in Action | |
| author | Martin Logan, Eric Merritt, Richard Carlsson |
| pages | 500 |
| publisher | Manning Publications |
| rating | 9/10 |
| reviewer | Rick J Wagner |
| ISBN | 1933988789 |
| summary | Teaches you to apply Erlang's message passing model for concurrent programming |
Section 1 has chapters that cover the following: basics of Erlang and OTP, Erlang language fundamentals, writing a TCP-based RPC server, OTP and the supervisor model, and graphical tools to help your development efforts. Language newbies will spend some time here, as Erlang can be a little odd to programmers coming from non-functional environments. (Concepts like recursion are given great coverage, as it should be.) OTP, the Erlang ubber-framework, is explained in detail as well. Section 1 alone would make a decent book on Erlang, but there is much more here.
Section 2 covers building a production application. The example given is a caching application, designed to increase throughput of a web application. In addition to expected topics like logging and an event-framework, the reader is exposed to Erlang's built-in distributed database, Mnesia. Application packaging and deployment considerations are also covered here.
Chapters in section 2 follow a helpful pattern to guide the reader through building an application. First, there is an introduction to some high level concept. Next, it is shown how this new widget can be used to further the needs of our production-worthy caching application. Finally the authors provide code that brings the desired functionality into the ever growing caching application. Erlang code tends to be somewhat dense-- not much code goes a long way-- so much of the latter part of each chapter is explanatory text explaining why you'd want to implement things in the way the authors did. Chapters in this part of the book read like an in-depth tutorial, and that's not a bad thing.
The third section of the book shows how to integrate with external users via HTTP, how to allow programs written in other languages to communicate with your Erlang code, and how to tune your environment. It's notable that Java gets a whole chapter on integration, through JInterface (in comparison, Joe's book offers about 4 lines on this topic. In fairness, that's a much older book, though.)
Throughout the book, simple illustrations are used to demonstrate key concepts. I found these to be extremely helpful, as Erlang in general is quite different than most programming languages. The delta between Erlang application development and other-language development is an order of magnitude different than something like the difference between Java and Ruby or Python and .Net. It's got different characteristics and different concepts. Given these large differences, I really appreciated the illustrations.
The book covers language built-ins like management tools, profilers, etc. (If you've ever used GNU development tools to profile an application, some of these might look a little familiar). The reader is given a lot to think about, and it's scattered over nearly 400 pages. To make a Java analogy, it's like an all-in-one book that teaches the language, the JDK and tools, JEE, and shows how to integrate your enterprise application with external entities. It's ambitious, but the book does a good job in explaining everything. That's why the impressive page-count helps. A skinnier book probably wouldn't be able to pull all that off.
The book is written with easy-to-understand anecdotes that help the reader grasp the finer points of Erlang craftsmanship. You definitely get the impression the authors have written 'real' code, and they offer strong direction to guide the reader through constructing application code. There is a big difference between understanding language syntax and understanding best practices in application construction. Section 2 in particular is loaded with best practices, and this alone makes this book a worthwhile read for Erlang coders writing production applications.
Probably the best thing I can say about this book is that the authors seem to put the advancement of Erlang above all else. To bolster that statement, I'd point out that they give the reader a list of other Erlang books they may wish to read, and they also include several mentions of Joe Armstrong. (Joe is the author of what has been the most popular Erlang book.) In my opinion, the authors can afford this indulgence, as this book is strong enough to merit inclusion on the Erlang programmer's bookshelf.
So who is this book good for? I'd recommend this book to anyone who wants to program in Erlang. It can get beginners off the ground, and will reveal many best-practices to those who already know their way around Erlang.
You can purchase Erlang and OTP in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I'm sure that both Erlang programmers... (Score:1)
will just love this book.
Oh, and by the way, "First!"
Haskell is in a similar position (Score:3, Funny)
But apparently the Haskell comunity found a programmer that actually care about Haskell [blogspot.com] just last week, they are now up to 38 people. I quote:
People see words like monads and category theory," Briars continued, swatting invisible flies around his head for emphasis, "and their Giving a Shit gene shuts down...
Re:Haskell is in a similar position (Score:4, Informative)
Neither was Erlang. It was intended as a domain-specific language for writing high-availability telecoms software, which is not allowed any downtime (therefore requires live patching) and must scale to an almost arbitrary degree. It just turned out that these requirements were very similar to a lot of Internet servers.
And if you've ever written a server in Erlang and then gone back to another language, you'll really miss being able to do pattern matching on binaries.
Re: (Score:2)
I think Prolog deserves an honorary mention here, as that's what the first Erlang interpreter/runtime was built in. (Actually, it shows through Erlang syntax.) People usually don't know how powerful Prolog is for Domain Specific Language creation.
Re: (Score:1)
Would you please explain why you think that Prolog is powerful for DSL creation? This is an honest question, because the language fascinates me and I would like to experiment using it for a project one day, but I have never run into a situation where it looked to me like writing a program in Prolog would be easier than using some other language+library.
Re: (Score:2)
Prolog has very strong pattern matching functionality. The SLD derivation mechanism that it uses for term rewriting lets you almost write the grammar for your language and have it execute automatically, just write the pattern on the left of the rule and what it means on the right.
It's not a good way of writing fast language implementations, but it's a very fast way of prototyping them. It can also be used to write compilers pretty easily.
Re: (Score:2)
There's good tutorial about DSLs in Prolog here:
http://www.cs.sunysb.edu/~warren/xsbbook/node10.html [sunysb.edu]
Re: (Score:2)
And if you've ever written a server in Erlang and then gone back to another language, you'll really miss being able to do pattern matching on binaries.
Could you give a high-level explanation on what pattern matching means here, and why I might want to do it?
Re: (Score:2)
I guess what GP didn't understand was the "binaries" part. I mean, Erlang runs in a virtual machine.
Re: (Score:2)
Erlang has a binary type, which is basically a blob of data. You can define patterns on a variable of this type with double angle brackets, so you can put stuff like this as an argument to a case statement:
<<1:32/big, UUID:128, Data/binary>> -> handlePacket(UUID, Data)
This would match a packet that starts as a 32-bit, big-endian, value of 12 and then contains at least 128 more bits. The next 128 bits would be stored in the variable UUID, while the remainder would be in the variable Data
Re: (Score:2)
I think I see what you mean and how that'd be nice, but I admit that I kept thinking "kind of like a C struct!" while reading it. It might be like wondering why you'd ever want a program to modify its own parse tree and why Lisp macros are such a big deal to those who have used them: until you've had them, you don't really miss them.
Re: (Score:2)
but I admit that I kept thinking "kind of like a C struct!" while reading it
C structures are like Erlang tuples. Binaries are like byte arrays. Consider the trivial problem of parsing and handling a packet from a network in C. The read() or recv() function gives you an array of bytes. You then have to construct a struct from it. You can do this by casting it to a packed structure, but then you still have endian problems and you typically have a performance penalty from the unaligned loads and stores. Then you have to have a bunch of if or case statements to find out exactly w
Re: (Score:2)
Technically, C has bit fields [gbdirect.co.uk] although in practice they are best avoided due to the alignment and ordering being implementation defined.
Re: (Score:2)
C bit fields are really just a way of cramming limited-range integers into a structure to save some space, they're not usable for manipulating bits (and C, of course, in spite of being a 'low-level' language doesn't expose the CPU's native bit manipulation operations to the programmer, unless you want to use compiler-specific intrinsics...).
D used to have a bit type, which was a lot more useful. You could define arrays of bits and then manipulate individual bits as if they were arrays of any other type.
Re: (Score:2)
Re: (Score:2)
I've been batting nearly 1000 over the last many decades dismissing each new wiz language that comes along.
(Ok, two failures out of a career.)
So I guess I'll dismiss this one as well.
The problem is that even when a language comes along that is perfectly suited foe some specific task, adopting it means 6 months of writing crappy code because you don't yet understand the language, and 6 years trying to find some one to maintain the system once its completed.
The time is far better spent canning some routines i
Re: (Score:3)
But apparently the Haskell comunity found a programmer that actually care about Haskell [blogspot.com] just last week, they are now up to 38 people. I quote:
Blah. Can't feel a lot of respect for any programmer who doesn't cultivate an appreciation for different styles of expression. To me that's a fundamental aspect of improving myself as a programmer.
Still, the bit about "hired a Perl hacker" was funny. For sure one of the big temptations in thinking too hard about programming is failing to get anything done. :)
Re: (Score:2)
Re: (Score:2)
Actually wasn't Erlang written for and successfully used by Ericsson in telco control and/or billing software with some insanely low amount of system down-time? Never figured out why the more business-minded innovative leaders in software didn't pick up on that and find some programmers willing to drop their prima-donna loves for mainstream languages to give writing some other software in it to see if the results for uptime could be duplicated.
Re: (Score:3)
Re: (Score:2)
I can count the number of programmers sufficiently rounded enough to consider learning a functional language "trivial" on my fingers.
I think there are lot of very rounded programmers around here. Especially around the midriff.
They've all experienced much personal growth and have stretched their limits many times. They carry a lot of weight in any discussion.
Re: (Score:2)
Well, damn (Score:1)
Re: (Score:3)
I was heavily considering writing a book on Erlang. It's a good thing I didn't. God only knows what the market for Erlang publications would be like if there were THREE books to choose from!
Don't forget Erlang: The Movie!! [youtube.com]
Re: (Score:1)
Re: (Score:2)
ejabberd is written in Erlang (Score:2)
The new 'IT' gift of 2010 (Score:3)
With this book, no one will EVER guess what you gave them, it is truly original.
Pick up your copy today, makes a great stocking stuffer!
Re: (Score:1)
Doulb-plus! Even if, by some miniscule chance or miracle, they manage to guess that it's a book on Erlang you've given them without even unwrapping it, imagine how surprised they'll be when they see the cover! No-one EVER would have guessed a book on programming languages would have THAT cover!
Re: (Score:3)
Re: (Score:2)
But you can interface directly with C libraries for stuff not suited to Erlang, and then do the Erlang for the messaging and coordination.
OTP? (Score:2)
OTP? "One True Pairing?"
Re:OTP? (Score:4, Informative)
The cover (Score:1)
That does NOT look like a good cover for a book on computer programming!!!
You must have both Erlang books... (Score:1)
...so you can read them concurrently.
Erlang x Manning OTP (Score:3)
What with being more up on the activities of fan-fiction authors than the activities of the Erlang world (it's really a fine slicing of 'vaguely aware of' for both), I keep wanting to read "OTP" as "One True Pairing", and wonder who Erlang is supposed to be having an imagined relationship with.
I'm not sure I want to google for the real meaning of OTP in this context. I kinda like the mental images.
Mnesia is unstable on Ubuntu 10.04 (Score:3)
Just a warning for anyone thinking of picking up Erlang programming. The Mnesia database is unstable under 10.04 -- so unstable that it loses the entire database every few restarts of an application.
Re: (Score:1)
The Mnesia database is unstable under 10.04 -- so unstable that it loses the entire database every few restarts of an application.
Well it lost the 'a' from the front of of its name, so it's no wonder it forgets stuff.
Re: (Score:1)
Just a warning for anyone thinking of picking up Erlang programming. The Mnesia database is unstable under 10.04 -- so unstable that it loses the entire database every few restarts of an application.
Do you have any references for this? I have used Mnesia on Ubuntu 10.04 and I haven't lost any data yet. However, I am about to use this combination on a mission-critical system so I really need to know if there is a problem.
Dont forget "Erlang Programming" (Score:2)
Dont forget "Erlang Programming" http://oreilly.com/catalog/9780596518189/. Its been out for a while