Erlang and OTP in Action | Hacker News Reader

Erlang and OTP in Action

manning.com

61 pointssigna1129 comments

This is on my Christmas list to my fam. I've been looking forward to reading it ever since ErlangCamp, which was organized by some of the authors, and fully awesome. If the book's as helpful as ErlangCamp was, then I expect this book to deepen my understanding of OTP, which in the O'Reilly and PragProg books seem to be more of a "if you want, you can do OTP". I prefer the "this is the way it should be done" approach. OTP should be the norm, rather than the exception, and a lot of new Erlang developers miss that (including myself).

You are right on target. OTP should be the norm and should be learned as a first step. Later on for curiosities sake one can learn to program without it! OTP codifies many of the best practices that experts in this type of process based concurrency model use every day.

It is nice to be finished with the book and we are really proud of it. These days we are back to Erlware, resurrecting the project from a two year hibernation, and also planning for the next ErlangCamp.

Martin, one of the problems with Joe Armstrong's book and OTP is that Joe doesn't use OTP - he always rolls his own servers - bless him. I remember everyone giving him dogs abuse for it over dinner at the Erlang Users Conference 3 or 4 years ago.

I do think we need to be all GNU/Linuxy about it and just always refer to it as Erlang/OTP.

The other books spend more time easing the reader into concepts like immutability, pattern matching, supervision hierarchies, and the concurrency model. This book is for when you're sold on Erlang-the-language's overall design, but still not sure about how to set up a real project on Erlang-the-platform.

I'd recommend getting all three, or one of the other two and this one. I like the Armstrong book's personality more - Cesarini's seems better organized, but a bit too serious.

Also: ErlangCamp was indeed fully awesome.

An aside: How bad is Erlang's string handling in practice? I primarily write server software, and Erlang would be a pretty good fit for much of what I do... but I also have to munge a lot of text pretty regularly, and I've been a little scared off by the FUD surrounding Erlang & strings.

Working with strings in Erlang hasn't been much of a problem for me. The re module's ( http://erldocs.com/R14B/stdlib/re.html?i=0&search=re: ) regular expression handling is pretty decent, and it takes binaries, iolists, and of course normal strings (just lists of ints).

Erlang strings are just lists of ints, but it's important to know the speed consequences with dealing with the ++ operator, or lists:flatten (which is supposed to be pretty slow, or so I've heard - never personally benchmarked). Binaries, on the other hand, are more like typical strings in other languages, and don't have the same performance penalty.

I'd say: play with it, do some benchmarks, and see how it fits for you. It's pretty easy to tinker with things on the Erlang Shell (like any REPL) so go for it. If it doesn't work well enough for you, ask the Erlang Mailing list, which is pretty good at ferreting out speed improvements (recent relevant optimization thread: http://www.trapexit.org/forum/viewtopic.php?t=19541&post... ).

And if all that fails for you, then you at least know you gave it a shot and can rule it out.

Personally, I think the language is freakin' awesome.

I just did a followup test to see just how the re:replace function did with converting a 16kb text string with a BBCode parser I've written in Erlang, and on my crappy laptop it did 1000 conversions in 12 seconds. Further, I'm not running the high-performance version of Erlang, nor did I do any attempts at parallelization optimization.

Surprising to me was that the performance difference between binaries and strings wasn't too much different.

Module: https://github.com/choptastic/Yabbie/blob/linux/site/src/lib...

(keep in mind, this is built with the Nitrogen Web Framework in mind, so if you want to run it stand-alone, you can comment out the include lines and it should work just fine).

  (nitrogen@127.0.0.1)9> bbcode:benchmark("l4d.txt",1000).
  [{binary_time,12841.423},{string_time,12888.905}]

So 12000 milliseconds for 1000 iterations each. A few millisecond difference (46 millisecond difference) isn't much of a difference.

That measurement would probably be more useful if stacked against same in Java / Python / Ruby / etc.

Writing the parser itself in Erlang seems expensive; passing text through discount (http://www.pell.portland.or.us/~orc/Code/discount/) in an otherwise Erlang system seems like a good neutral measure.

(and then 100k threads doing same concurrently)

Absolutely. Perhaps I'll do a more elaborate comparison between a few other languages just to see.

People coming from most other languages don't realize that atoms ("symbols", in Lisp) can be used for many things that would otherwise be done with strings. This really helps - pattern-matching on atoms is niiiice. Like much of Erlang, it makes lots of sense to people with Prolog experience, but ... who has Prolog experience? (lone hand) Oh.

Many of the performance issues (++, etc.) apply to any language with immutable strings, or any other immutable data structures. Clojure, Haskell, etc., but nobody harasses Clojure about being "bad for strings" - There's just a FUD meme about Erlang going around.

You can also do string handling via a port (an external program in C, or any other language), if it's a major performance issue - Erlang is happy to pass messages to an external program in any language. Lua has a similar design* . It focuses on doing certain things really well, and for the rest, there's an easy escape; no harm, no foul. "You want to run some eeevil code? Just run it in another process, we'll send data to it and handle the results if ze sleazy bastard doesn't crash..."

* And immutable strings - In Lua, all strings are atoms by default.

Try standardizing on "strings as binaries" instead of "strings as lists" within the app. I've found it an elegant and efficient way to deal with text. I believe the root of the issue with pretending strings are lists of integers is that it is not possible to tell the difference between an integer list and a "string". If you use binaries for strings, all of the issues simply go away.

I already own the book, but I wanted to let others know that it is the Manning 'Deal of the Day' today (12/05/10.) You can get it for $25 if you enter promotional code dotd1205ccb when you checkout.

Thanks! Worked for me.

A colleague just recommended this book last week.

Thanks! Worked for me too.

Also, the somewhat-related RabbitMQ in Action is half off today, with code n3050. (After reading the first chapter, it puts zeromq in perspective, if you search HN discussions about it.)

On the topic of Erlang books... does anyone know what the story is with Geoff Cant's "Mastering Erlang: Writing Real World Applications"?

It was due out around October from memory, but seems to have slipped into limbo.

http://www.amazon.com/Mastering-Erlang-Writing-World-Applica...

I'd go so far as to say that this is one of the best technical books I've read. I'd been interested in Erlang for a while, but found building anything in OTP somewhat baffling. I read this and it clicked. I just wish the rest of Erlang's documentation was even half as good as this.

If you're doing marketing supposably for friends, you could at least link to a blog post about the book.

I like Joe's, and the o'reilly book better. The examples aren't that great on this one and unlike the book claims the other books do cover some OTP. Read this one only after you've read the first two books, but even then I don't know if it was worth it.

I have all three, and think they're complementary. I like Joe Armstrong's book, but don't think it's very good as a reference - it jumps around too much. The O'Reilly book is better organized, but with both, OTP comes in kind of as an afterthought. I'm glad to have another that focuses primarily on it, because there are too many details about paths, deployment, etc. to just have one chapter about it 2/3 of the way through. I didn't realize how many common issues OTP completely handles until the presentations at ErlangCamp.

My thoughts agree. I made it about halfway through the other two books before things kind of fell apart and I didn't really know how to apply Erlang IRL.

Just bought this and hoping it completes the picture.

I don't think I'm doing anything illegal here, by posting the coupon that Manning sent out for free yesterday to the subscribers to the "Deal of the day" list. This coupon will permit to buy this book (paper and pdf) for 25$: dotd1205ccb

I highly suggest this book, it's definitely one of the best about Erlang. I also suggest subscribing to the ML, some books from Manning are great (thinking about the joy of Clojure for example).

The only book that covers OTP in depth. Cesarini and Armstrong one are equally essential for learning Erlang programming.

I hope you like the book and checkout what else we are working on : erlware.org and erlangcamp.com

I have been working through the book, and I'm just getting into the meat of it. I'm tempted to skip ahead to the JInterface chapter though to noodle around with some erlang powered graphics.

quite excited about reading this, I have been hearing some excellent feedback about this book already.

Great book on Erlang/OTP teaching from an OTP perspective. Must read if you're into Erlang at all.

Great book to learn OTP!

OTP has to be one of the poorest chosen acronyms in the computing industry. It has been used as 'One Time Pad' for decades.

Reply on news.ycombinator.com