Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

Whoever ranked the parent a Troll is either devoid the ability to sense humor or somehow is a Haskell fan that just happened to have mod points. Face it, Erlang, Haskell, and even OCaml are not popular languages outside of the mathematical and scientific communities. Even I as a programmer tried to pick up all three, to a degree succeeded in learning the syntax and grasping the concepts, but hit a dead end when I found out all three are missing many things that are required to create actual real world appli

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.

I doubt it. Erlang has pretty good documentation. There's a book that you can download that describes the core language and parts of OTP, and the various OTP modules all have detailed documentation. When I learned Erlang, the idea of buying a book about it never really occurred to me. The language itself is pretty tiny (and sufficiently similar to Prolog that it's easy to pick up). I've written a couple of concurrent server apps with Erlang, although I wouldn't describe myself as an Erlang programmer.

Really? There's nothing especially complicated about functional languages, and once you've learned one, then learning the next one is pretty easy. I don't think someone could describe themselves as a rounded programmer if they've only ever used imperative languages. Oh, and going from Prolog to Erlang is probably easier than going from something like Haskell to Erlang (more similar syntax, type system, and pattern matching semantics), and Prolog is one of the languages that I'd expect anyone who wants to

Everyone needs more programming languages in their life this holiday season, and everyone loves Erlang!
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!

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!

Erlang's strength is scalability, not performance. If you've got something that's numerically intensive, Erlang is unlikely to give you better performance than C unless you're using a really big cluster or a supercomputer. HiPE does pretty well on floating point if you make sure that the type inference can work correctly, but even then it's not very close to C performance. That said, it's now much easier to call C from Erlang than it used to be, so you can pretty easily write the performance-critical par

Open Telecom Platform. Erlang was created for writing telephone switching systems, and so the standard library that it comes with was named with this in mind. It's a bit of a silly name now, because it contains a load of stuff that would be no use for telecoms, but which are pretty useful in other situations.

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.

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.