losvedir
I’ve always used String.to_existing_atom/1 without issue after verifying that the atoms are in the codebase somewhere.
However, I noticed that starting with Elixir 1.14, the docs for the function carry this guideline:
Since Elixir is a compiled language, the atoms defined in a module will only exist after said module is loaded, which typically happens whenever a function in the module is executed. Therefore, it is generally recommended to call
String.to_existing_atom/1only to convert atoms defined within the module making the function call toto_existing_atom/1.
I’m trying to better understand how Elixir is compiled, loaded, and run. I don’t understand the limitation that the atoms need to be in the same module for this to be reliable. I found Issue with loading existing atoms from other modules · Issue #4832 · elixir-lang/elixir · GitHub which was about inconsistent behavior where the atoms weren’t always available, so it seems to be a real problem.
Suppose my app is deployed as a mix release. If the String.to_existing_atom/1 function is looking at runtime for existing atoms, why wouldn’t any atom in the code work? I would expect all the code to have been compiled prior to the release running, so wouldn’t the lookup always work?
Maybe the guideline is around partial compilation in the test environment or something like that?
Or maybe my mental model of an “internal atom database” that gets queried is wrong. Maybe the code compilation essentially inlines a mapping lookup in the code right at the time that it’s compiled?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 2- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
al2o3cr
In Erlang’s “interactive mode”, modules aren’t loaded until they are referenced.
So if a function in
Foodoes aString.to_existing_atomexpecting to find an atom defined inBar, it could fail if nothing else has yet referencedBar.IIRC releases run in the other mode (“embedded mode”) so that can’t happen.
gregvaughn
Note “generally recommended”. Using atoms in the same module is always safe and doesn’t require any deeper knowledge of how the BEAM handles atoms. But it’s not necessary to do that.
If (building on @al2o3cr 's example)
FoorequiresBardirectly or indirectly, thenBars atoms will be available even in interactive mode. However, that brings in additional concerns about compile time dependencies that were out of scope for the simple recommendation in the docs.