Learn You Some Erlang for Great Good! (a review)

Learn You Some Erlang for Great Good! (LYSE) is one of the best books to learn about the programming language and the system Erlang/OTP. This article includes a brief review about LYSE of No Starch Press version, my impression about the author Fred Hébert (Fred), and related miscellaneous things.

Fred is a young person. I assume he was born in the late 1980s. That itself makes LYSE extraordinary. The writing style of LYSE is purely casual and conversational; it's quite different from other Erlang classics, such as Joe Armstrong's Programming Erlang (I'm eagerly waiting for the Second Edition!) and Erlang Programming of Francesco Cesarini and Simon Thompson (I'm also eagerly waiting for a new book from the authors with Robert Virding this time!), let alone the first book of Erlang called Concurrent Programming in Erlang published in the 1990s. Those classic books are written by much older people, and they follow the traditional textbook format. LYSE does not. You will also be surprised by the illustrations drawn by Fred. Those drawings are so creative that I've even got distracted with them while reading the otherwise very technical and detailed contents. Maybe I've got too old. Nevertheless, you need to know LYSE is not an ordinary textbook.

I've seen no book on Erlang about the complete coverage of the language and the OTP library other than the online manual at erlang.org and the source code repository at GitHub. LYSE is not a manual either; it is rather a collection of live stories and practical examples of Erlang based on the hard-earned experience of Fred himself. It's written for those who actually write the code, develop the packages, and release the products. For those who want to study from the very beginning, I recommend Simon St. Laurent's Introducing Erlang.

I will avoid digging into explaining the whole contents of LYSE, because the explanation will take the same amount of words the book has. LYSE is a thick book which has approximately 600 pages, so it's not something for an easy reading. I have to confess there are many things I didn't know and I haven't tested yet in the book. The book hyper-comprehensively covers the necessary topics for dealing with the day-to-day tasks on Erlang/OTP development, from the language basics to gen_server, (the rage against the) finite state machines, package release, Mnesia and the OTP internal database modules, and a proposal of how to read all the Erlang punctuations in English.

In LYSE, the semantic details of the language and system elements of Erlang/OTP are meticulously well-written. One of the most impressive contents is about the intentional avoidance of tail-call optimization in the try-catch exception handling; Fred simply writes:

The protected part of an exception can't be tail recursive.
(Chapter 7, “Protecting The Right Thing")

I will not explain the reason here, but this sort of caremad attitude in the details makes LYSE a professional handbook, if not a textbook (and it is not, I repeat.)

Fred is a very talkative and energetic person. I really admire the level of his English fluency especially when he makes a thunderstorm-like (real) lightning talk. He is also helpful and has assisted a lot of newcomers as his erlang-questions mailing list articles show. The book represents his personality very well. If you are an experienced programmer, LYSE is also an interesting book as a general reading, because the book will remind you of how you have been self-teaching yourself.

I recommend LYSE to all those who want to learn Erlang and OTP, especially to those who want to experiment and self-learn the language and system. If you want to know the contents first, check out the free online version.

Appendix: about the book title

When I saw the title of LYSE first time, and when I saw the title of the cousin book of LYSE about Haskell called Learn You a Haskell for Great Good! (LYAH), I thought there was something severely wrong with the grammar, even from a speaker of English as a second language. I've learned at school that the verb learn will not take a person as the object, and so does my New Oxford American Dictionary built into OS X say. I had a hard time to explain the meaning of this sentence to some Japanese experts who are not familiar with this type of non-standard English sentence. And I have to confess the phrase “Great Good” looked non-standard to me too.

On the other hand, the title of LYSE looks much more understandable to me if I see it as a literal translation of a non-English Indo-European language. Fred is a proud francophone Quebecker, and he is also an excellent English speaker and writer. I can imagine Fred reads and understands the title of LYSE in a complete different manner than I do. So I will complain no more about the title of LYSE or LYAH.

Disclaimers

I've been sent a review copy of LYSE from No Starch Press on January 2013. In this article I mostly refer to the No Starch Press version, though I also have read the online free version. Note well: I have ordered and purchased my own copy of LYSE from No Starch by myself before receiving the review copy!

I should also note that I've met Fred at least three times at Erlang Factory SF Bay Area 2011, 2012, and 2013, so this review may be heavily biased. (I hope this review is not too late, Fred!)

Acknowledgment

Thanks to Jessica Miller of No Starch Press for sending me a copy of LYSE and helping me about what to do with the 600 pages of paper :)

It's all about experience

It's not just the programming.
It's not just the music.
It's not just the message.

It's all about experience. And the desire for it.

People are looking for a new experience through technologies.

Concurrency will surely help giving a smooth experience; and even more good things.

(I will not quote Jimi Hendrix here)

My technical interests for Erlang/OTP as of April 2011

This is a list of my technical interests for Erlang/OTP as of April 2011:

• Catching up the latest cryptographic algorithms, including hash functions, shared-key cryptography, public-key cryptography, pseudo random number generators (PRNGs), while making them efficient in parallel/concurrent execution environment;
• Delay tolerance network technologies which can handle days, weeks, months of message delivery delays;
• Fundamental support functions of IPv6, especially for Distributed Erlang and epmd, and cryptographic transport support with SSL/TLS;
• DNSSEC-compatible resolver implementation for inet_res module;
• Large binary heap handling of BEAM, and the programming methodologies for the faster NIF implementation, including the performance measurement;
• PRNGs with small context/internal-state size, e.g., Wichmann-Hill 1982/2006, LShift, XOR32;
• PRNGs with large context/internal-state size, e.g., SFMT;
• TAI or leap-second handling by NIF;
• Privilege separation techniques between BEAM instances (e.g., virtualization, FreeBSD Jail); and
• the effective usage and choice of port drivers, linked-in drivers, and NIFs

And projects I'm interested in (but not limited to):

• Disco Project, a MapReduce implementation
• ZeroMQ and other general queueing systems
• UBF, BERT-RPC, and other messaging formats
• CouchDB

And don't forget I'll be hosting the ACM Erlang Workshop 2011.

(This article is a revised version of http://heikou-konton.blogspot.com/2011/02/erlangotp.html (originally written in Japanese.)

Why choosing Erlang for concurrent processing

A few weeks ago I was reading a blog article called Erlang, the next Java. While I agreed with the author's views, I felt something was bugging me in the article, which eventually lead me to write this blog article.

I didn't choose Erlang just because it's a functional language. I have chosen Erlang to learn because Erlang programming requires and has to enforce the programmers to write the concurrent code. Concurrent programing should minimize the number and size of critical regions and bottlenecks. And I think writing such programs is very difficult without the assistance of the programming language.

Many programming languages claim or plan to be capable of running a part of code based on concurrent processing. For example, Ruby will incorporate distributed storage mechanism called Roma and the task administration subsystem called Fairy. Another good example is Haskell concurrency: it is implemented as a language feature called Parallel Haskell.

I think, however, introducing concurrency while allowing programmers to write code to use shared memory will cause a lot of problems. Joe Armstrong has already described his concern on shared memory in his blog. I support his arguments; those arguments an important part of the reason why I decided to learn Erlang.

I should add another problem programmers will face when dealing with code allowing shared memory; rewriting the code for removing shared access to run it efficiently on concurrent environment will be an incredibly difficult task.

Unfortunately, most existing languages have already had a lot of code written assuming shared memory areas. For example, C code with extern variables implicitly assume those are shared between the functions in all source code files linked together. I assume I can hardly find any set of C code without using an extern declaration. I have learned that even Common Lisp has special declaration for the variables, which allows multiple functions share the same object, out of lexical scopes.

Another example of shared-memory concurrency is the operating system (OS) threads. C/C++/Java threads inherently share the parent OS process address space and environment in common. Python has the Thread Objects. While OS threads often ease implementation of concurrent servers by reducing the task switching time, the semantics is implicit and error-prone.

I understand and agree that sharing objects itself cannot be completely eliminated under the read-world constraints of processing and communication timings between programming language functions. I think, however, that programming languages should help the programmers to minimize writing code including shared memory areas, which will turn themselves into critical regions.

Erlang imposes necessary restriction on avoiding implicit data sharing between functions by:

• prohibiting multiple variable assignments in a function;


• enforcing and helping the programmers to conduct message-passing programming between functions, by not providing any implicit data-sharing facility between the functions;


• providing fast task-switching capabilities, by giving the definition that functions are the minimum concurrent execution units; and


• restricting the usage of data-sharing facilities between functions to the minimum, such as process dictionaries, ETS, DETS, Mnesia, and the global naming service shared between connected Erlang nodes, by requring explicitly writing so in the code.
  

In short, I think adding concurrent features is not enough for concurrent programming; prohibiting non-concurrent habits and enforcing writing concurrent programs are necessary as part of the programming language specifications. I believe concurrent programming under coming multi-processor environment is only possible under such a hard-liner attitude to the programmers. I feel programmers including myself are very conservative and rigid to change their sequential-programming habits.

And actually, I was one of those programmers who did not recognize the urgency of learning concurrent programming in 2007.