Does Erlang (and Elixir by extension) provide a way to remove atoms? [duplicate]

Question

Can atoms be removed from a running Erlang/Elixir system?

Specifically, I am interested in how I would create an application server where modules, representing applications, can be loaded and run on demand and later removed.

I suppose it's more complicated than just removing the atom representing the module in question, as it may be defining more atoms which may be difficult or impossible to track.

Alternatively, I wonder if a module can be run in isolation so that all references it produces can be effectively removed from a running system when it is no longer needed.

EDIT: Just to clarify, because SO thinks this question is answered elsewhere, the question does not relate to garbage collection of atoms, but manual management thereof. To further clarify, here is my comment on Alex's answer below:

I have also thought about spinning up separate instances (nodes?) but that would be very expensive for on-demand, per-user applications. What I am trying to do is imitate how an SAP ABAP system works. One option may be to pre-emptively have a certain number of instances running, then restart them each time a request is complete. (Again, pretty expensive though). Another may be to monitor the atom table of an instance and restart that instance when it is close to the limit.

The drawback I see with running several nodes/instances (although that is what an ABAP system has; several OS processes serving requests from users) is that you lose out on the ability to share cached bytecode between those instances. In an ABAP system, the cache of bytecode (which they call a "load") is accessible to the different processes so when a program is started, it checks the cache first before fetching it from storage.

Answer 1

Unfortunately not, atoms are not destroyed within the VM at all until the VM shuts down. Atom limits are also shared across processes, meaning that spawning a new process to handle atom allocation/deallocation won't work in your case.

You might have some luck spawning a completely separate VM instance by running a separate Erlang application and communicating to it through sockets, although I'm not sure how effective that will be.