The Joe Armstrong Archive

In case you are not aware, Joe Armstrong passed away recently :cry: as a way to remember him, perhaps we can use this thread to compile an archive of all his best bits - whatever you think they may be, whether from his mailing list/forum posts or threads or blogs or talks or books or in fact anything you think worth including.

If you want to look through his posts here you can do so here and his threads here.


I loved his how to reverse a list video I think it captures his personality and approach to problem solving perfectly.

Here’s one I posted not long ago - his thoughts on the benefits of Erlang’s ‘term_to_binary’:

Databases are basically rectangular tables of cells, where the cells contain very simple types like strings and integers - every time you access a row of an external database this list of cells has to be converted to beam internal data structures - this conversion is extremely expensive.

The best way to persist data is in a process - then no conversion is needed, but this is not fault tolerant - so you need to keep a trail of updates to the data and store this on disk.

Often you don’t need a database for example you might like to have a system where you store all the user data as in the file system with “one file per user” this will scale very nicely - just move the files to a new machine if you need more capacity.

Erlang has two primitives term_to_binary and the inverse binary_to_term that serialise any term and reconstruct it - so storing complex terms on disk is really easy.

I have mixed feelings about databases, they are great for aggregate operations (for example, find all users that have these attributes) but terrible for operations on individual users (where a single file per user is far better).

If I were designing a new system I’d go for ‘one file per user’ as much as possible and try to limit databases for operations over all users.

From: Acceptance of Erlang's 'term_to_binary' and vice versa in Elixir


I found this talk fascinating especially the parts of considering physics limitations when designing systems and how programmers are the best job creators :laughing: by creating complexity that needs maintenance, sadly as a new member in the community I didn’t get to interact with him but I hope I can learn more from him as I dive more into elixir and erlang :rocket:


My favourite:

Thanks, Joe.


Definitely @ferd’s article –

And the links inside:


You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

The wrong stuff is a bitch. You boobed, but you are forgiven if the good stuff outweighs the bad. This is the stuff you want to remove later, but you can’t because of backwards compatibility and some nitwit has written a zillion lines of code using all the bad stuff.

Amazing but true

When I’d finished this article, I wanted to spell check the content. emacs-ispell mode decided to go on strike. It could not find aspell, the program that I use for spelling checking.

My emacs spell checker has worked faithfully on this machine for several years. And just when I complain that I spend half my life fixing things that shouldn’t be broken the emacs spell checker decides to break.

I don’t believe in malicious Gods, nor that the laws of physics are different in the left-hand corner of the sofa in my front room where I’m typing this, though there is circumstantial evidence to suggest the contrary.

I could see no reason why my spelling checker should break - Everything is fine, I have changed nothing. Well I have installed a new version of Erlang and installed Julia and written some lecture notes since I last spell checked a document.

Fortunately eleven minutes with the Google casino worked. The second suggestion of how to fix my problem worked - and I still don’t know why emacs could not find aspell - and life is too short to find out why.

I guess there are some things we’ll just never know.

$ erl -sname gandalf


My fav picture of joe <3



Remarkable about this post is, how it took of. See the comments.
Here is the talk to it:


Scala, Erlang, F# Creators Discuss Functional Languages