When looking at the elixir-lang docs on tuples iex> {:ok, "hello"}, tuple = {:ok, "hello"} , I see :ok being introduced out of thin air (unless it is introduced elsewhere), but when I try this sequence
I get the error report ** (MatchError) no match of right hand side value: {:ok, #PID<0.185.0>}
so I assume that :ok is a special atom. I can see atoms like :nil, :true and :false. Is there a list of special atoms in Elixir that can’t be used elsewhere?
:ok is a atom, like all other atoms it will not be garbage collected.
The reason you’re getting a match error, is because the Plug.Adapters.Cowboy.http.MyRouter function will return a tuple in the format of {:ok, pid} (This is very common in Erlang/Elixir).
The tuple {:df, _} will not match the tuple {:ok, pid} because the atoms are different
Also think of it this way since you implied you use C and such in other posts, think of an atom as a named integer, every one is unique in the system and any of the same name will always match any other very fast. Quite literally at compile time the atom :ok in code is replaced with an integer so the comparisons are integer-fast (though the integer is packed in the tagged type properly, just like integers but a different tag).
Atoms are compiled into the code when loaded in the VM (not at compile-only time), if an :ok is in code then it is statically defined. In essence this happens:
Code is loaded into the VM
The VM runs passes over the code
One of those passes looks at atoms, looks up the atom name (up to 255 bytes of basically anything) in the global atom table, if it finds it then it replaces the atom in the source with an integer of the index into that table, if it is not found then it makes a new entry and uses that index
If multiple nodes connect then the first time they communicate any atom between them they creating a mapping of indexes to indexes to make for fast communication
That is why it cannot be garbage collected, it may be used by other nodes once connected, it is used inside the compiled code in the VM, etc…
There are some functions that directly access the atom table, one of those is calling to_string on an atom, it looks up the atom’s index in the atom table and returns the string. Another can get the atom index of a string and create it if it does not exist, and another does the same but will error if it does not exist (always use that one if you need it).
So it does not matter where it is defined or used or anything, every module in every location gets the same atom index. It is only set at VM time, not compile-time.
Atoms are never assigned any value. You can think of them as constants, where the value of the atom is the name of it. The value of the atom :ok is :ok
With regards to atoms not being garbage collected, every atom declared in the lifetime of a program will be stored in an atom table. If you create atoms dynamically (through user-input), at some point the atom table will consume too much memory and the VM will be killed. This is just something to be aware of
Actually no atoms are garbage collected, whether created in code or dynamically at runtime, and they are kept in the atom table for fast comparison. Amongst other things this means that you should be very careful if you have a program which dynamically creates atoms because when the atom table fills up the system crashes. By default the size of the atom table is 1000000 which means that it will never be filled with atoms written code.
The size of the atom table can be set at startup time.
