On Failure (Computing)

Tuesday, May 31, 2011 :: Tagged under: pablolife plt engineering. ⏰ 3 minutes.


Hey! Thanks for reading! Just a reminder that I wrote this some years ago, and may have much more complicated feelings about this topic than I did when I wrote it. Happy to elaborate, feel free to reach out to me! 😄


While I'd also like to speak of personal failures today, I've been thinking a lot more about system failure.

Alan Perlis famously wrote that you shouldn't bother to learn a programming language unless it changes the way you think about programming, and Erlang delivers in spades. Almost a year in* to ScrabbleCheat, only now do I feel like I'm understanding the value (and love) of Erlang. Namely, what it means to write dependable software.

Another blog post said it best: "Erlang is about building reliable systems." Singling it out to concurrency, or distributed systems, or hot-code loading, or simply for it's functional nature is missing the point.

It's not immediately obvious: the most used and referred-to book for newcomers trying Erlang is Joe Armstrong's Programming Erlang. This was my first book learning Erlang, and while it has a great tone and expresses many of the introductory concepts clearly, it sadly seems a bit out of date, and has it's priorities in the wrong order. If you only read the first 200-300 pages, you come out not knowing exactly how big a deal the OTP is.

As an example, an entire chapter on using Makefiles to build your code is probably unnecessary: any developer worth their salt knows enough about Makefiles to compose shell commands, and that's essentially all he demonstrates.

I don't mean to be too hard on it, but here are some tips/resources for those interested in exploring Erlang:

You'll never really love the language until you design a proper application with OTP. While every book/tutorial wants you to write a chat server, I rather enjoy optimization problems, like ScrabbleCheat.

Back to failure: after programming in Erlang, I feel naked in other languages without supervisors and trap_exits. Lack of proper Actors means distribution (and therefore fault-tolerance) is a chore, never mind the concurrency benefit. Erlang has been a dream to play with, and I would recommend you do a hobby project or two in it ^_^

*= Madly Brilliant and I joke about the fact that I've been working on this for so long. Really, it's been about a year since the initial commit, where I implemented trie using gb_trees, way before I had even heard of a GADDAG. While I like to say "a year in" to make it sound like a major commitment, I've sadly only gotten to work on this very rarely. Were I someone who hadn't just moved into a city and started my first job while maintaining an overseas-then-cohabitating relationship, I would call this 2-3 months of real work.

Thanks for the read! Disagreed? Violent agreement!? Feel free to join my mailing list, drop me a line at , or leave a comment below! I'd love to hear from you 😄