Hacker News new | ask | show | jobs
by waisbrot 2848 days ago
One example that I hit frequently:

An "atom" is an Erlang/Elixir thing, kind of like an enum value. "true" and "false" are implemented as atoms, you might create atoms to represent connection states ("idle", "connecting", "connected", "disconnecting"), or to represent errors ("file_not_found", "no_permission", etc). It's a really useful thing and something I miss in every language that doesn't have it.

In Erlang, a variable is a token that begins with a capital letter ("UserId") and anything that begins with a lowercase letter is either a keyword ("if", "case", "end") or an atom. Since keywords are a finite set, this is pretty straightforward. Module names and function names are atoms, so there's no additional complexity there.

In Elixir, a variable is a token that begins with a lowercase letter, unless it's a keyword or one of the special atoms "true", "false", and "null". An Elixir atom either starts with a capital letter (typically module names) or has a ":" in front of it (":file_not_found") or has a ":" after it when used as a map key ("file_error: :file_not_found" -- both words there are atoms).

So the problem that I run into is that identifying whether a token is an atom and, if so, if it's the same atom as in another spot, requires more thought than I think it should.

My Elixir experience was that there were quite a few cases like this where I hit minor friction. In general, I felt that Elixir code is a little easier to write but a little harder to read and Erlang code is a little harder to write but a little easier to read. I feel like the latter situation should be much preferred.

2 comments

This is just coming from an Erlang background. For those of us who came from other languages, atoms are often implemented with the colon syntax (ruby, julia)

The reverse colon syntax was a bit wierd, but it (and including the parser assuming that it's in a list when it's the last term) make parameter lists buttery.

Just a note:

The atom for "null" is actually `nil`.