The way tail recursion is implemented in BEAM is quite interesting. Instead of automatically allocating stack frames when you enter a function and deallocating on return like many VMs do, in BEAM this stack management in manual - you get a allocate n instruction which allocates a stack frame of size n and a corresponding deallocate n instruction that does the reverse. This means that some functions that don’t need stack space don’t allocate anything at all in the first place, but other functions can deallocate their stack frame before calling the last function - this effectively is a tail call optimisation.

Additionally Erlang (and Elixir) implement a slightly more powerful version of tail recursion optimisation called last call optimisation, where not only recursive calls are optimised, but all calls in the “tail” or “last” position are optimised. This makes it trivial to tail-optimise mutually recursive functions (a calls b which calls a which calls b …), which is very hard or impossible in other schemes.

The other thing worth pointing out is that, because we know data is immutable, the language compiler can perform a bunch of optimizations, such as storing constant values in a literal pool so you don’t allocate new memory on every use, being able to point to existing data types as we know they won’t mutate, etc.

Elixir has tail call optimization, so if the last thing a recursive function does, is call itself the compiler can optimize this. Here’s a blog post about it Tail Call Optimization with Fibonacci in Elixir | Stride