[erlang-questions] Why should you ever use atoms?

Jesper Louis Andersen <>
Sat Oct 10 22:14:22 CEST 2015

On Sat, Oct 10, 2015 at 5:46 PM, Thomas Gebert <> wrote:

> I know this is probably kind of a newbie question, but I figured this
> would be the place to ask it: if atoms aren't garbage collected, why should
> I use them?

1) Pierre notes: runtime characteristics are different. This in itself is
an important reason.

Having a way to introduce static names in code with O(1) comparison helps
in defining structure. This structure can then be used in pattern matches
to quickly discriminate between cases. If you define

    {user, "tombert", "easts pizza"},

you are using a common pattern where the first tuple-argument encodes what
the remainder of the tuple contains. It has some reminiscence of algebraic
datatypes in languages which support those, and is somewhat Erlang's ways
of getting access to these.

>From a programmers perspective:

atoms: used for statically declared words by the programmer and are avoided
for dynamic generation and input controlled by an "enemy".
binaries: used in places where space saving is paramount, and for data
which contain truly binary information.
strings: textual strings and the rest of the systems string-like objects
are represented as lists of code-points.

Apart from this, there are cases where it is nice to signify "namespace
difference" by using atoms. e.g., in the term

    {user, "tombert", "eats pizza"},

A reader immediately understands that 'user' is something the programmer
has supplied, whereas "tombert" and "eats pizza" are probably sattelite
data entered by a user at some point. Had we writte, e.g., "user", then you
somewhat tell the reader that "user" is a field which might get changed to
"anything", whereas the atom 'user' signifies that there might be other
kinds of terms used in this place, but there is only a finite amount of

Of course, YMMV, and some people have other views as to how and where to
use the different classes. There are also people who thinks we should GC
atoms such that we can reuse them freely. The major reason this has not
happened yet, is that one has to come up with a good scheme that doesn't
slow the interpreter down too much, or breaks the soft-realtime properties
of the system.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151010/353356ec/attachment.html>

More information about the erlang-questions mailing list